1322668 - Enable EV for TeliaSonera Root CA v1 root

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Root Program, task)

Description

[pekka.lahtiharju]

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served

Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):

Certificate Details
-------------------
(To be completed once for each certificate; note that we only include root
certificates in the store, not intermediates.)

Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy
   (i.e. what you plan to do with the root)
 - Number and type of subordinate CAs
 - Diagram and/or description of certificate hierarchy

Certificate download URL (on CA website):
Version:
SHA1 Fingerprint:
Public key length (for RSA, modulus length) in bits:
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):

CRL HTTP URL:
CRL issuing frequency for subordinate end-entity certificates:
CRL issuing frequency for subordinate CA certificates:
OCSP URL:

Class (domain-validated, identity/organizationally-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code signing):
URL of example website using certificate subordinate to this root
(if applying for SSL):

Comment 1

[pekka.lahtiharju]

CA Details
----------

CA Name: TeliaSonera Root CA v1
Website: https://repository.trust.teliasonera.com

"TeliaSonera Root CA v1" is the main root CA for Telia Company. It is a commercial CA creating SSL and Client certificates for Nordic customers. We are offering certificates for server authentication, client authentication, email (both signing and encrypting), but not for code signing. Now we want to expand to EV SSL certificates.

Audit Type (WebTrust, ETSI etc.): Webtrust
Auditor: Ernst&Young
Auditor Website: www.ey.com
Audit Document URL(s):
https://support.partnergate.sonera.com/download/CA/audit2016.pdf
https://support.partnergate.sonera.com/repository/TeliaCompanyBRAuditReport.pdf
https://support.partnergate.sonera.com/download/CA/TeliaSonera%20-%20WebTrust%20for%20CA%20-%20Extended%20Validation%20SSL%20-%20Auditor's%20Report%20and%20Management%20Statement%202016-01-25.pdf

Certificate Details
-------------------
Certificate that should be EV enabled has fingerprint:
SHA-1: 43 13 bb 96 f1 d5 86 9b c1 4e 6a 92 f6 cf f6 34 69 87 82 37

Certificate Name:
The root has a new sub-CA (TeliaSonera Extended Validation SSL CA v1) that will be used to enroll EV certificates accorging to our EV policy that has been documented in our Server CA CP/CPS: https://repository.trust.teliasonera.com/TeliaCompany_Server_Certificate_CPS_v1.6.pdf. Other sub-CAs under the same root are intact.

Certificate download URL (on CA website): 
http://repository.trust.teliasonera.com/teliasonerarootcav1.cer
Version: v1
SHA1 Fingerprint: 43 13 bb 96 f1 d5 86 9b c1 4e 6a 92 f6 cf f6 34 69 87 82 37

Public key length (for RSA, modulus length) in bits: 4096 bits
Valid From (YYYY-MM-DD): 2007-10-12
Valid To (YYYY-MM-DD): 2032-10-12

CRL HTTP URL:
CRL issuing frequency for subordinate end-entity certificates: 2 hours or under
CRL issuing frequency for subordinate CA certificates: 12 months or under
OCSP URL: http://ocsp.trust.teliasonera.com

Class (domain-validated, identity/organizationally-validated or EV): Now IV,OV and EV
Certificate Policy URL: 
https://repository.trust.teliasonera.com/TeliaCompany_Server_Certificate_CPS_v1.6.pdf
CPS URL:
https://repository.trust.teliasonera.com/TeliaCompany_Server_Certificate_CPS_v1.6.pdf
Requested Trust Indicators (email and/or SSL and/or code signing): email and SSL like before
URL of example website using certificate subordinate to this root
(if applying for SSL): https://repository.trust.teliasonera.com/

Comment 2

[pekka.lahtiharju]

Attachment: screenshot showing successful completion of EV testing

Screenshot in pdf format showing successful completion of EV testing

Comment 3

[pekka.lahtiharju]

The original link to the acceptance of our root CA is 

Bug 539924 - Add TeliaSonera Root CA v1 root certificate 
https://bugzilla.mozilla.org/show_bug.cgi?id=539924

Comment 4

[Aaron Wu]

Hi Pekka,

I have started this certificate information verification process, I need your help to make sure that you have acknowledgement our policy and also identify in which CP/CPS section describes each of following items:

please read through our wiki link provided below.

Recommended Practices:

1. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices

1) Publicly Available CP and CPS: (please provide direct links)
2) CA Hierarchy: (please provide which sections in CP/CPS, same for all following items)
3) Audit Criteria: 
4) Document Handling of IDNs in CP/CPS: 
5) Revocation of Compromised Certificates: 
6) Verifying Domain Name Ownership: 
7) Verifying Email Address Control: 
8) Verifying Identity of Code Signing Certificate Subscriber:  
9) DNS names go in SAN: 
10) Domain owned by a Natural Person: 
11) OCSP: 
12) Network Security Controls:


Problematic Practices:

2. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

1) Long-lived DV certificates:
2) Wildcard DV SSL certificates:
3) Email Address Prefixes for DV Certs: 
4) Delegation of Domain / Email validation to third parties: 
5) Issuing end entity certificates directly from roots: 
6) Allowing external entities to operate subordinate CAs: 
7) Distributing generated private keys in PKCS#12 files: 
8) Certificates referencing hostnames or private IP addresses: 
9) Issuing SSL Certificates for Internal Domains: 
10) OCSP Responses signed by a certificate under a different root: 
11) SHA-1 Certificates:
12) Generic names for CAs: 
13) Lack of Communication With End Users: 
14) Backdating the notBefore date:

Thank you very much!

Comment 5

[Aaron Wu]

Attachment: CAInformaion_TeliaSonera_InfoNeeded_20170320.pdf

Comment 6

[Aaron Wu]

Hi Pekka,

Based on the CPS and the information you provided in Comment#1, I've verified and enter into Salesforce. Please see attachment in Comment#5 and we need your information input and clarify which marked as "Need Response from CA" and "Need Clarification from CA"

For CA/Browse Forum Test, there are two errors shown as:
**Error 1: CA certificates must set keyUsage extension as critical
Meaning: The Baseline Requirements say that the keyUsage extension MUST be present and MUST be marked critical.
Recommended Solution: This requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. In general, CAs should not be requesting inclusion of CA certs created before that date.

**ERROR 2: CA certificates must include countryName in subject 


For Test Websites, please provide (i) valid, (ii) revoked, and (iii) expired.
Note : CA Browser Forum section 2.2: “The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates .."


Thank you so much!

Kind regards,
Aaron

Comment 7

[pekka.lahtiharju]

Hi Aaron,

You had so many questions it took some days to find out all the answers. But here are all the answers. At first the explanations to the errors in your comment 6:

**Error 1: Our root certificate was created in 2007 when there was no valid BR processes. We are not asking you to add that old root again (already included) but to add EV flag to it. All our newer CA certificates and especially "TeliaSonera Extended Validation SSL CA v1" that is valid in this request do have keyUsage extension as Critical.

**Error 2: Our root certificate was created in 2007 when there was no valid BR processes. We are not asking you to add that old root again (already included) but to add EV flag to it. All our newer CA certificates and especially "TeliaSonera Extended Validation SSL CA v1" that is valid in this request do have countryName in the subject (c=FI). Back in 2007 our Company had two home countries and we tried to avoid pinpointing either of those.

**Test Websites:
(i) valid: https://juolukka.cover.sonera.net:10443/
(ii) revoked: https://juolukka.cover.sonera.net:10444/
(iii) expired: https://juolukka.cover.sonera.net:10445/
(iv) EV/valid:  https://repository.trust.teliasonera.com

**Comment5 answers:

1) Publicly Available CP and CPS: (please provide direct links)
ANSWER:
CP&CPS: https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v1.7.pdf
and because our CP&CPS text is hierarchy this text is also valid for all our CA certificates: https://repository.trust.teliasonera.com/Telia_Production_CPS_v2.5.pdf

2) CA Hierarchy: (please provide which sections in CP/CPS, same for all following items)
ANSWER: Server CPS section 1.3.1

3) Audit Criteria: 
ANSWER: 
Server CPS section 8.1. New audit is ongoing and new results expected in 06/2017.

Webtrust Audit is based on Trust Services Principles and Criteria for Certification Authorities v.2.0. Audit report is here:
https://support.partnergate.sonera.com/download/CA/audit2016.pdf

SSL audit is based on Webtrust Principles and Criteria for Certification Authorities - SSL baseline with Network security - Version 2.0. Audit report is here:
https://support.partnergate.sonera.com/repository/TeliaCompanyBRAuditReport.pdf

EV audit is based on Webtrust for Certification Authorities - Webtrust Principles and Criteria for Certification Authorities - Extended Validation SSL - Version 1.4.5. Audit report is here:
https://support.partnergate.sonera.com/download/CA/TeliaSonera%20-%20WebTrust%20for%20CA%20-%20Extended%20Validation%20SSL%20-%20Auditor's%20Report%20and%20Management%20Statement%202016-01-25.pdf

Independent link to our audit seal (https://cert.webtrust.org/ViewSeal?id=2061) can be found here if you click WebTrust image: https://repository.trust.teliasonera.com/CPS

4) Document Handling of IDNs in CP/CPS:
ANSWER:
Server CPS section 3.2.2 defines how domain name value is verified. In our process all names are visually verified. IDN spoofing issue is included in our internal verification training material.
 
5) Revocation of Compromised Certificates: 
ANSWER:
Server CPS section 4.9 defines our revocation process.

6) Verifying Domain Name Ownership: 
ANSWER:
Server CPS section 3.2.2 defines our domain verification process. Telia has internal verified list of public WHOIS registers for domain name owner verification purposes. In each verification we copy-paste the registrant section which defines the owner to our internal evidence database. Organization data in whois record must match with the subscriber. Fields used for this purpose are Organization ID and Organization name. In unclear cases all other information is also verified like addresses and phone numbers. 

7) Verifying Email Address Control: 
ANSWER:
Email address may be part of Telia user certificate. Its CPS is separate from SSL and can be found here: 
https://repository.trust.teliasonera.com/Telia_Organizational_User_Certificate_v1.3.pdf
Section 3.2.3 defines the process. In practice Telia either sends one-time-password to email address to be verified so than end-entity must use the otp from there before they can get the certificate. Or in Enterprise cases Telia pre-verifies that domain name in email addresses belong to the Customer using SSL domain verification rules. In the Enterprise case it is 
Customer operator that is responsible that the unique component of email address (chars before @) is valid within email domain scope.

8) Verifying Identity of Code Signing Certificate Subscriber:  
ANSWER:
Telia doesn't issue Code Signing certificates.

9) DNS names go in SAN: 
ANSWER:
Server CPS section 3.1.1 defines SAN usage. In Telia certificates SAN is mandatory for all DNS names.

10) Domain owned by a Natural Person: 
ANSWER:
Server CPS section 3.1.1 defines O value. Telia won't create SSL certificates to natural persons.

11) OCSP: 
ANSWER:
Server CPS section 4.9 and especially 4.9.9 defines Telia OCSP. OCSP has been tested also with FF.

12) Network Security Controls:
ANSWER:
The publicly available part of Telia Network security are documented here: https://repository.trust.teliasonera.com/Telia_Production_CPS_v2.5.pdf. Network security is one of the key areas Telia continuosly improve. Network security is part of the annual audit made according to "SSL baseline with Network security - Version 2.0".

**Problematic Practices:

1) Long-lived DV certificates: NA (Telia won't issue DV certificates)
2) Wildcard DV SSL certificates: NA (Telia won't issue DV certificates)
3) Email Address Prefixes for DV Certs: NA (Telia won't issue DV certificates)
4) Delegation of Domain / Email validation to third parties: 
Telia includes all certificates under Telia roots to Telia's annual audits. Same rules apply to all third parties which are valid for Telia.
5) Issuing end entity certificates directly from roots: NA (Telia won't issue certificates directly from roots (except sub-CA))
6) Allowing external entities to operate subordinate CAs: 
Telia includes all certificates under Telia roots to Telia's annual audits.  Same rules apply to all third parties.
7) Distributing generated private keys in PKCS#12 files: Possible with Telia SMIME certificates but delivery channel is always https-protected. PIN code is delivered by other channel (SMS or email).
8) Certificates referencing hostnames or private IP addresses: Telia hasn't allowed private addresses or names for years. SAN field is the primary field for IP address and DNS name. CN may have a copy of one value.
9) Issuing SSL Certificates for Internal Domains: Telia hasn't allowed private addresses or names for years.
10) OCSP Responses signed by a certificate under a different root: NA (Telia uses always OCSP Responder from the same root)
11) SHA-1 Certificates: Telia deprecated SHA-1 in 11/2014. 
12) Generic names for CAs: NA (Telia won't use generic names)
13) Lack of Communication With End Users: NA (Telia is responsive)
14) Backdating the notBefore date: NA (Telia uses current time stamp for notBefore)

Comment 8

[Aaron Wu]

Hi Pekka,

Thanks for your response! I am verifying the data you provided and entering into Salesforce.

In the meanwhile, please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Thank you so much!


Kind regards,
Aaron

Comment 9

[pekka.lahtiharju]

Attachment: Telia CA BR Self Assessment v0.4.xlsx

At last Telia CA was able to finish the newly required BR Self Assessment. Result is attached.

Comment 10

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 11

[Kathleen Wilson]

Attachment: 1322668-CA-Information.pdf

Please review the attached file for accuracy.

Please also respond to the one item with status "Need Response from CA", which is:
https://certificate.revocationcheck.com/repository.trust.teliasonera.com
Errors:
ThisUpdate is more than seven days old, CRLs must be updated and reissued at least every seven days
ThisUpdate is more than four days old, OCSP information must be updated at least every four days (Mozilla & Baseline Requirements)

Comment 12

[pekka.lahtiharju]

I've reviewed the attachment in comment 11. You could fix that Telia will start also enrolling DV type SSL certicates (now listed only OV end EV). DV additions are already included in our newest CPS.

The first listed problem…

Location: http://crl-3.trust.teliasonera.com/teliasonerarootcav1.crl
ThisUpdate is more than seven days old, CRLs must be updated and reissued at least every seven days (Mozilla Maintenance Policy section 3)

…isn’t against BR or Mozilla because root CRL can be older that 7 days like stated in BR 4.9.7:

"For the status of Subordinate CA Certificates: 
The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field."

Our sub-CA CRL has only 2 day validity time like listed in the test report and thus is compatible also. We don't understand why the test page gives this error regarding our root CRL.

The other listed problem…

Location: http://ocsp.trust.teliasonera.com
This update: Jan 5, 2018 2:00:00 AM
Next update: Jan 5, 2019 2:00:00 AM
Produced at: Feb 28, 2018 8:29:29 AM
Status: Good
ThisUpdate is more than four days old, OCSP information must be updated at least every four days (Mozilla & Baseline Requirements)

...was an error in our new OCSP system configuration. It is fixed now. Now it is refreshed daily and next update is ten days from This update.  New output can be seen below:

#  openssl ocsp -issuer root.crt -nonce -CAfile root.crt -url http://ocsp.trust.telia.com -serial "0x9938B8D60628EA592E26010FD266E811"
Response verify OK
0x9938B8D60628EA592E26010FD266E811: good
        This Update: Mar  1 00:00:00 2018 GMT
        Next Update: Mar 11 00:00:00 2018 GMT

Comment 13

[David E. Ross]

Re comment #12:

The Mozilla policy section 6 says: "For end-entity certificates, CRLs MUST be updated and reissued at least every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field."  

BR 4.9.7 is a minimum requirement.  When the Mozilla policy sets a more rigorous requirement than the BRs, the Mozilla policy overrides the BRs.

Comment 14

[Wayne Thayer]

(In reply to David E. Ross from comment #13)
> Re comment #12:
> 
> The Mozilla policy section 6 says: "For end-entity certificates, CRLs MUST
> be updated and reissued at least every seven days, and the value of the
> nextUpdate field MUST NOT be more than ten days beyond the value of the
> thisUpdate field."  

The policy quoted above does not apply to root CRLs, and that's what this is. For some reason the revocationcheck.com site is not detecting that the certificate is an intermediate and thus the CRL is a root CRL that may be valid for up to 12 months. My guess is that the caIssuers extensions is causing the confusion because that's not normally present in a certificate signed by a root. In any case, I think this is a false positive.

Comment 15

[Kathleen Wilson]

Attachment: 1322668-CA-Information-Final.pdf

Comment 16

[Kathleen Wilson]

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

Comment 17

[Wayne Thayer]

I have begun the review of this request and identified the following issues:

* Telia’s current BR audit contains 4 qualifications: https://support.partnergate.sonera.com/download/CA/WebTrust-BR-Audit-Report-2017-06-30.pdf
* Telia was one of the CAs whose OCSP responder was returning a ‘good’ response for unknown certificates. The problem was fixed fairly quickly but a full incident report has not yet been supplied: https://bugzilla.mozilla.org/show_bug.cgi?id=1426247
* Telia currently has two intermediate certificates that have not been fully disclosed: https://bugzilla.mozilla.org/show_bug.cgi?id=1451953. New technically constrained versions of these certificates have been issued and Telia plans to revoke the unconstrained intermediate certificates.
* 3 key usage errors in certificates issued by the Server CA intermediate since 2017 [5]. None are revoked.
* 21 certificates containing encoding errors issued by the Extended Validation SSL CA intermediate since 2017: https://crt.sh/?cablint=538&iCAID=22371&minNotBefore=2017-01-01. Some, if not all, remain unrevoked.
* 4 certificates containing an organizationName but no localityName or stateOrProvinceName issued by the Gateway CA intermediate since 2017: https://crt.sh/?caid=1661&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01. None are revoked.

It is unlikely that this request will ever be approved following a public discussion of these issues.

Pekka: which of the following options would you like to choose:
1. I can continue my review and put this request out for public discussion now.
2. Put this request on hold until new audits are received and the other issues are resolved. In this case, please be aware that these issues will still be discussed and may cause the request to be denied.
3. Cancel this request.

Comment 18

[pekka.lahtiharju]

Thanks for reviewing this! Please check my question below on KU issue.

We choose the option 2 (put this now on hold). We'll need few weeks to fix the issues. None of them is very serious in our assessment nor hard for us to fix. Fixing plan is:

OCSP:	This was an old bug in our new CA/OCSP software. Vendor has fixed it. We'll create a proper incident report.

SubCA:	These relate to SMIME bit of two issuers. Previously it was allowed in subCA level on two issuers even though it isn't needed. Fully constrained subCA certificates already exist for these. Next we'll revoke the old/unused subCA certificates causing this issue.

KU:	EC and RSA keys now create similar Key usage (KU) bits. Those KU bits are not appropriate for EC keys. We'll separate KU handling depending on the key algorithm. Is this a serious issue so that we should revoke the 3 incorrect ones? Those are used by our customers and we hesitate to revoke those unless required. They seem to work OK.

EV test:We revoke the incorrect EV test certificates. We also have to fix encoding of 1.3.6.1.4.1.311.60.2.1.3.

L:	There was previously an incorrect profile setting for IP valued SSL certificate. It didn't require L. It has been fixed last autumn. Next we'll replace/revoke the 4 incorrect ones that are still valid. Those are used by Telia's SSL VPN devices.

Comment 19

[Wayne Thayer]

(In reply to pekka.lahtiharju from comment #18)
> KU:	EC and RSA keys now create similar Key usage (KU) bits. Those KU bits
> are not appropriate for EC keys. We'll separate KU handling depending on the
> key algorithm. Is this a serious issue so that we should revoke the 3
> incorrect ones? Those are used by our customers and we hesitate to revoke
> those unless required. They seem to work OK.

This is your decision to make, but I do believe that these certificates violate section 7.1.2.4 of the BRs. RFC 5480 clearly defines acceptable Key Usage values for ECC certificates. By not revoking these certificates, I believe you are further violating BR 4.9.1.1(9).

Comment 20

[pekka.lahtiharju]

Telia would like to re-activate our EV application now. All issues listed in comment 17 have been fixed:

* Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1426247 has now full incident report
* The two non-disclosed sub-CA certificates have been revoked and their status updated to both CRL and OCSP
* 3 certificates with incorrect KeyUsage have been revoked and root cause also fixed (EC has now its own certificate profile)
* 21 certificates with encoding errors are now either revoked, expired or pre-certificates only. Software bug that created the incorrect encoding to JurisdictionCountryName field has been fixed.
* 4 certificates with missing Locality value related to IP address in SAN have been revoked. System that generated those has been updated to prevent similar problem in the future.

Comment 21

[David E. Ross]

Should there be a new audit to examine whether the problems cited in comment #17 will not occur again?

Comment 22

[Wayne Thayer]

2018 audit reports are due by the end of this month. Please update this bug when they are available.

Comment 23

[pekka.lahtiharju]

2018 audit reports are now inserted to CCADB and are also available here:
https://support.trust.telia.com/download/CA/TeliaWebTrustForCAReport2018.pdf
https://support.trust.telia.com/download/CA/TeliaSSLBaselineReport2018.pdf
https://support.trust.telia.com/download/CA/TeliaEVWebTrustReport2018.pdf

There was one notified audit issue in Webtrust Audit report and few issues in BR report. Telia public response to those can be found from link https://repository.trust.teliasonera.com/TeliaAuditPublicResponse2018.pdf

Comment 24

[Wayne Thayer]

I have reviewed these new audit statements and Telia's response to the 9 BR qualifications. Based on this information, combined with my review of Telia's policies and practices, I have concluded that I do not recommend approval of this request and that this request should not proceed to a public discussion (the results of which would almost certainly be a rejection). I am closing this bug as WONTFIX. Telia is welcome to submit a new application for a new root that is not the subject of the issues described in this bug.

Here is an updated list of issues that I have compiled for this request:

==Good==
* Telia plans to issue EV certificates from a dedicated intermediate certificate.
* Methods for requesting revocation are clearly spelled out on section 1.5.2 of the server CPS

==Meh==
* One instance of SHA-1 issuance was recorded in 2016 [1].
* According to the Telia Server CPS, they plan to continue using domain validation methods 1 and 5 until the deadline of 1-August.

==Bad==
* Telia’s current BR audit contains 9 qualifications [2]. Telia’s response [3] includes statements that they still need to remediate issues 1,3,4,5,6,7, and 9. They do not plan to revoke misissued certificates identified in finding #4. The prior audit had 4 qualifications [4].
* Telia was one of the CAs whose OCSP responder was returning a ‘good’ response for unknown certificates. The problem was fixed fairly quickly but a full incident report was not supplied until 6 months after the incident [5].
* Telia had two intermediate certificates that were not fully disclosed [6]. New technically constrained versions of these certificates have been issued and Telia revoked the unconstrained versions after this was brought to their attention.
* 3 key usage errors in certificates issued by the Server CA intermediate since 2017 [7]. They were revoked after the issue was brought to their attention, but another was issued on 15-June for CN=*.webtv.telia.com and it is not revoked.
* 21 certificates containing encoding errors issued by the Extended Validation SSL CA intermediate since 2017 [8]. Those that were not revoked prior to informing Telia have now been revoked.
* 5 certificates containing an organizationName but no localityName or stateOrProvinceName issued by the Gateway CA intermediate since 2017 [9]. All were revoked once the problem was reported to Telia.
* More than a year elapsed between version 2.2 and 2.3 of Telia’s Root CP/CPS in violation of Mozilla policy section 3.3.
* Server CPS [10] section 4.2.4 states “If a CAA record exists that does not list Telia as an authorized CA, Telia verifies that the applicant has authorized issuance, despite the CAA record.” The BRs do not permit CAs to choose to ignore CAA records in this manner.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1315019
[2] https://support.trust.telia.com/download/CA/TeliaSSLBaselineReport2018.pdf
[3] https://repository.trust.teliasonera.com/TeliaAuditPublicResponse2018.pdf
[4] https://support.partnergate.sonera.com/download/CA/WebTrust-BR-Audit-Report-2017-06-30.pdf
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1426247
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1451953
[7] https://crt.sh/?caid=1634&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[8] https://crt.sh/?cablint=538&iCAID=22371&minNotBefore=2017-01-01
[9] https://crt.sh/?caid=1661&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[10] https://repository.trust.teliasonera.com/Telia_Server_Certificate_CPS_v2.1.pdf