Add Telia CA root certificate
Categories
(CA Program :: CA Certificate Root Program, task, P1)
Tracking
(Not tracked)
People
(Reporter: pekka.lahtiharju, Assigned: bwilson)
References
Details
(Whiteboard: [ca-approved] - in Firefox 100, NSS 3.77)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/18.17763
Steps to reproduce:
Root CA incusion for Telia Root CA v2
Actual results:
At present the Telia CA Root CA v2 certificate is not in Mozilla store
Expected results:
Inclusion of Root certificate in Mozilla store
|
Reporter | |
Comment 1•4 years ago
|
||
Telia Finland Oyj (part of Telia Company AB) operates the Certificate Authority (CA) services (https://support.trust.telia.com/index_en.html). Telia CA, as non-governmental organization, delivers certificates to companies registered in following countries: Finland, Sweden, Norway, Denmark, Estonia, Latvia and Lithuania. Telia CA has been included in Mozilla and now we have created a new Root CA called “Telia Root CA v2” to comply with new Baseline Requirements (BR), changing the legal name (O=TeliaSonera to O=Telia Finland Oyj), and increasing the validity time of the Telia Root CA from 2032 to 2043.
Currently we have two root CAs included in Mozilla trust store: Sonera Class2 CA and TeliaSonera Root CA v1. As described previously Telia Root CA v2 is as new root CA shall be added to Mozilla CA certificate store. Telia Root CA v2 is cross-signed by TeliaSonera Root CA v1.
Webtrust auditors have performed the WebTrust 2.2 and Network Security v2.4 audits in addition to Root Key generation ceremony audit. The audit result indicates Telia Root CA v2 compliance with Mozilla requirements. For further information see the following links:
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 2•4 years ago
|
||
The information for this root inclusion request is available at the following URL.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000660
|
|
Assignee | |
Comment 3•3 years ago
|
||
Today I reviewed this inclusion request in the CCADB at the URL above. I will move this into the queue for CPS review just as soon as I am able to resolve:
1 - authenticity of the BR audit letter from 2020-06-26, and
2 - resolve test web site error for https://juolukka.cover.telia.fi:10603.
|
|
Assignee | |
Comment 4•3 years ago
|
||
Resolved item 2 - test website passed.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 5•3 years ago
|
||
Pekka,
I am reviewing both your Server and your Client Certificate CP/CPSes. I am trying to understand your domain and email validation processes for these types of certificates to ensure that domain validation tasks are not delegated to third parties. Section 1.3.2 of the Baseline Requirements says “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.” While section 1.3.2 of your CP/CPS states “All RA functions for the Telia CA listed in this CPS are performed internally by Telia,” I did not find language specifically stating that domain validation is not delegated to any third party. Also, section 2.2.2 of the Mozilla Root Store Policy says, "The CA SHALL NOT delegate validation of the domain portion of an email address" (for enterprise-based issuance), but I could not find this concept expressed in your CP/CPS for Client Certificates. Section 3.2.4 of the Telia CP/CPS says, “Domain name ownership of domains in email addresses is not verified by Telia except when CA API is utilized by the Subscriber.” This seems contradictory. Can you point to places in your CP/CPSes that support the proposition that Telia is responsible for domain validation for these types of certificates?
Thanks,
Ben
|
|
Assignee | |
Comment 6•3 years ago
|
||
Telia CP/CPS Review
Certificate Policy and Certification Practice Statement for Telia Server Certificates (v.4.1)
https://cps.trust.telia.com/Telia_Server_Certificate_CPS_v4.1.pdf
Certificate Policy and Certification Practice Statement for Telia Client Certificates (v.3.0)
https://cps.trust.telia.com/Telia_Client_Certificate_CPS_v3.0.pdf
Both effective as of 2021-06-11
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)
Good – The documents follow the RFC 3647 framework without blank sections.
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions):
Attribution (CC-BY) 4.0
Attribution-ShareAlike (CC-BY-SA) 4.0
Attribution-NoDerivs (CC-BY-ND) 4.0
Public Domain Dedication (CC-0) 1.0
or a set of equally permissive licensing terms accepted by Mozilla in writing. If no such license is indicated, the fact of application is considered as permission from the CA to allow Mozilla and the public to deal with these documents, and any later versions for root certificates which are included in Mozilla's trust store, under CC-BY-ND 4.0.”
OK – According to https://creativecommons.org/licenses/ the Attribution-NoDerivs (CC BY-ND) license “lets others reuse the work for any purpose, including commercially; however, it cannot be shared with others in adapted form, and credit must be provided to you.” (The Telia policy documents state, “No part of this document may be reproduced, modified or distributed in any form or by any means, in whole or in part, or stored in a database or retrieval system, without prior written permission of Telia. However, permission generally applies for reproducing and disseminating this CPS in its entirety provided that this is at no charge and that no information in the document is added to, removed or changed.”)
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
Good – Section 1.1 of the Server CP/CPS states, “Both OV and DV certificates conform to the current version of the Baseline Requirements (BR) aka “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” published at http://www.cabforum.org. In the event of any inconsistency between this CPS and those documents, those documents take precedence over this CPS.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)
Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
Good - The Telia Root CA v2 has issued the following subordinate CA certificates with the following sets of EKUs:
Telia Class 1 CA v3 - ClientAuth, EmailProtection
Telia Class 2 CA v3 - ClientAuth, EmailProtection
Telia Class 3 CA v1 - AuthenticDocumentsTrust, DocumentSigning
Telia Document Signing CA v3 - AuthenticDocumentsTrust, DocumentSigning
Telia Domain Validation CA v3 - ClientAuth, ServerAuth
Telia Email CA v5 - ClientAuth, EmailProtection
Telia Server CA v3 - ClientAuth, ServerAuth
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
Good – The documents list the root CAs and intermediate CAs and Figure 1 contains the Telia Server Certificate PKI Hierarchy or the Telia CA Client Certificate PKI Hierarchy, respectively.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)
“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.
Good – There is a Revision History table. The document has been updated annually, and section 2.3 states, “This CPS is reviewed and updated or modified versions are published at least once per year and in accordance with section 9.12.”
Statement of Non-Delegation for Domain Validation (BR § 1.3.2)
“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”
Unclear – While section 1.3.2 of the CP/CPS states “All RA functions for the Telia CA listed in this CPS are performed internally by Telia,” I did not find language specifically stating that domain validation is not delegated to any third party. See Comment #5
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
Good – This is well-covered in section 1.5.2 of the CP/CPS.
Naming compliant with X.500, RFC5280 and BRs
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
OK – Naming is described in sections 3.1.1, 3.1.4, and 7.1.4.
No internal names or reserved IP addresses (BR § 7.1.4.2.1)
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
Good – Section 3.2.2 says, “Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name are not allowed, and there are internal checks to avoid issuing such certificates.” Similar language is in section 3.2.2.5.
ALL certificates must meet Mozilla/BR validation requirements
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Good – Section 3.2.2.4 specifies the allowed methods conforming to BR § 3.2.2.4.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2)
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Unclear – See Comment #5
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
Good – Section 3.2.2.7 of the CP/CPS for Server Certificates provides a set of criteria used by Telia to establish data source reliability.
All information in a certificate must be verified (MRSP § 2.2.1)
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
OK – Section 3.2.4 of the CP/CPS for Server Certificates states, “Only subject attributes listed in chapter 3.1.1 are supported and thus verified.” Section 3.2.4 of the CP/CPS for Client Certificates is less clear. Several places in the section say, “Other information is not verified by Telia or Subscriber Organisation.”
Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)
CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”
Needs to be fixed before 10/1/2021 – Section 3.3.1 of the CP/CPS for Server Certificates says, “The previous verification data may be utilized by CA if it is not expired as specified in chapter 4.2.1.” Section 4.2.1 says, “Telia may use its previously documented verification data. Old verification data will expire in 825 days in OV and DV. Old verification data including organisation name, address components, Parent/Subsidiary/name change relationships, authorisation documents and domain/IP ownership are stored related to organisation’s registration number if available.” Effective October 1, 2021, domain/IP ownership must expire after 397 days.
CAA record checking and recognized domain names in section 4.2 (BR § 2.2)
“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”
Good – Section 4.2.4 of the CP/CPS contain the appropriate CAA language.
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)
CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.
OK – Section 5.2.3 says, “Identification of the RA roles takes place within the CA and RA system applications and it is based on strong authentication either using personal operator cards, software based keys and certificates or other two factor authentication mechanisms depending on the policy requirements of the applicable CA.”
Pre-issuance linting (Recommended Practices)
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Should be mentioned – Telia should mention in its CP/CPS the linting or other pre-issuance steps it takes to prevent misissuance.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Needs to be fixed – Part of subsection 10 in section 4.9.1 of the CP/CPS (“Telia CA is made aware of a demonstrated or proven method that exposes the Subscriber’s private key to compromise, methods have been developed that can easily calculate it based on the public key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys),” should be moved to the 24-hour revocation portion of section 4.9.1.
SMIME Reasons for Revocation (MRSP § 6.2)
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events … 5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;” etc.
Should be fixed – Telia should compare MRSP § 6.2 with what it states in section 4.9.1 of its CP/CPS for Client Certificates.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)
Good – Section 4.9.7 of the CP/CPS states, “For server certificates: a. A new CRL is published at intervals of not more than two (2) hours b. The validity time of a CRL is forty-eight (48) hours”
Clearly specify methods to demonstrate private key compromise (MRSP § 6)
Section 4.9.12 of a CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise.
Needs to be fixed- Telia needs to explain the methods that a third party could use to demonstrate to Telia that a private key has been compromised.
CA must not allow certificate suspension (BR § 4.9.13)
Good – Section 4.9.13 of the CP/CPS says, “Suspension is not used after March 2013.”
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)
OK – Section 4.9.10 of the CP/CPS states, “The OCSP service is using near-real-time CA database information. The OCSP responder may use the previous status value for a certificate if it is fresher than two hours old (refresh time).” However, Telia should provide more details about its profile for OCSP Responses.
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Should be fixed – Telia should state that it will notify Mozilla (and other Application Software Providers, browsers and/or root stores) if a CA private key is suspected to have been compromised.
CA must not generate Subscriber key pairs (MRSP § 5.2)
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Good – Section 6.1.2 of the CP/CPS states, “Within DV and OV certificates Telia never creates private keys.”
Must meet RSA key requirements (MRSP § 5.1)
OK – Section 6.1.5 says “The CAs require that the Subscribers generate at least 2048 bit RSA keys or ECC curve NIST P256 or P384 keys.” And section 6.1.6 says, “Telia CA refuse to accept certificate request if it is containing a known weak RSA key.” Sections 6.1.5 and 6.1.6 could be improved with reference to pre-issuance checks that Telia could perform, or does perform, on key quality.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1)
OK – Section 6.1.5 says “The CAs require that the Subscribers generate at least 2048 bit RSA keys or ECC curve NIST P256 or P384 keys.” Sections 6.1.5 and 6.1.6 could be improved with reference to pre-issuance checks that Telia could perform, or does perform, on key quality.
Certificate lifetimes limited to 398 days (BR § 6.3.2)
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Good- Section 6.3.2 says, “DV and OV certificates are given a maximum validity period of 398 days.”
Network Security (MRSP § 2.1.2)
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
Should be fixed – Section 6.7 of the CP/CPS (and/or section 6.5) could be improved by incorporating the CA/B Forum’s “Network and Certificate Systems Security Requirements” by reference.
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
Should be fixed – Section 7.1 currently states, “The CA generates an individual serial number for every certificate. The number that has been given in this field is unique for every certificate created by the CA system. The software manages the uniqueness of the serial number automatically.” Telia should add that serial numbers are generated by a CSPRNG and are greater than zero and have at least 64 bits, or something to that effect.
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)
OK – Section 7.1.2 of the CP/CPS says, “The extended key usage purposes of the public keys contained in the OV and DV certificates include: Server authentication and Client authentication.”
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)
OK – Section 7.1.3 of the CP/CPS says, “SHA-1 functionality was discontinued in 2014 ….”
Any CN must also be in a SAN (BR § 7.1.4.2.2.a)
Good – CPS section 3.1.1.3 states, “The CN value is always one of the values contained in the Certificate’s subjectAltName extension.”
|
|
Assignee | |
Updated•3 years ago
|
|
||
Comment 7•3 years ago
|
||
(In reply to Ben Wilson from comment #6)
Telia CP/CPS Review
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions):
Attribution (CC-BY) 4.0
Attribution-ShareAlike (CC-BY-SA) 4.0
Attribution-NoDerivs (CC-BY-ND) 4.0
Public Domain Dedication (CC-0) 1.0
or a set of equally permissive licensing terms accepted by Mozilla in writing. If no such license is indicated, the fact of application is considered as permission from the CA to allow Mozilla and the public to deal with these documents, and any later versions for root certificates which are included in Mozilla's trust store, under CC-BY-ND 4.0.”
OK – According to https://creativecommons.org/licenses/ the Attribution-NoDerivs (CC BY-ND) license “lets others reuse the work for any purpose, including commercially; however, it cannot be shared with others in adapted form, and credit must be provided to you.” (The Telia policy documents state, “No part of this document may be reproduced, modified or distributed in any form or by any means, in whole or in part, or stored in a database or retrieval system, without prior written permission of Telia. However, permission generally applies for reproducing and disseminating this CPS in its entirety provided that this is at no charge and that no information in the document is added to, removed or changed.”)
Doesn't the "provided that this is at no charge" part contradict mozilla policy?
|
|
Reporter | |
Comment 8•3 years ago
|
||
Telia answers to CPS review:
Comment 5
Telia never delegates domain validation to third parties. We will clarify this to next CPS release.
In the server CPS sentence in 1.3.2 "All RA functions for the Telia CA listed in this CPS are performed internally by Telia" describe the fact that domain validation is only performed by Telia.
In the client CPS we have intended to convey that Telia itself always verifies email domain ownership or verifies that End-entity controls the email account, that is described in section 3.2. We'll improve client email domain validation description into the next CPS published in July. In practice Telia has three client use cases: a) Enterprise RA case (API case) where Telia pre-approves allowed email domain(s) using SSL domain validation, b) End-entity must show she/he controls the email account, c) SMIME is not allowed (constrained subCA).
Statement of Non-Delegation for Domain Validation (BR § 1.3.2)
See above
CA validates domain part of all e-mail addresses (MRSP § 2.2.2)
See above
Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)
Telia will update the Server CPS by August 16th when new configuration is activated.
Pre-issuance linting (Recommended Practices)
The Server CPS will be updated in July to include this statement: "Telia has multiple lint-like checks to verify certificate structure before enrollment to prevent any misissuance. Also Lint is used the night after enrollment to verify the syntax. Any failure in pre-checks will prevent enrollment and any failure in lint check would cause quick revocation according to this CPS."
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
Telia will revise the text in the next Server CPS revision in July.
SMIME Reasons for Revocation (MRSP § 6.2)
Telia will revise the text in the next Client CPS revision in July.
Clearly specify methods to demonstrate private key compromise (MRSP § 6)
Telia will revise the text in the next Server/Client CPS revision in July.
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)
Currently this process is described in internal documentation. Telia will include the text in the next Server/Client CPS revision in July.
Network Security (MRSP § 2.1.2)
Telia is following industry best practices and standards for all aspects of operations. We will include this fact in the next Server/Client CPS revisions in July.
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)
Telia generated serial numbers are compatible with this requirement. Telia will revise the text in the next Server/Client CPS revision in July.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Reporter | |
Comment 9•3 years ago
|
||
Now the new CPS documents for both server and client certificates are updated with responses to Mozilla's CP/CPS comments. These documents will be effective from July 15th 2021. The following links are now in public review until that date.
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 10•2 years ago
|
||
Public discussion period began and is scheduled to close on 22-Dec-2021. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/52Gfr4dnJD8/m/yn5fpfnACQAJ
|
|
Assignee | |
Comment 11•2 years ago
|
||
Public discussion closed today with a recommendation to approve the inclusion of Telia Root CA v2. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/52Gfr4dnJD8/m/a_BSUuxXCQAJ
|
|
Assignee | |
Updated•2 years ago
|
|
||
Comment 12•2 years ago
|
||
Note that I am going to wait on deciding what to do here until Moudrick's questions have been answered, and Ben and I have done further investigation. So clearing my needinfo for now.
|
|
Assignee | |
Comment 13•2 years ago
|
||
Hi Kathleen,
Please see my summary of the discussions related to Moudrick's questions and arguments:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/52Gfr4dnJD8/m/AEzVDa0CAwAJ
This is a request to approve Telia's request to include the Telia Root CA v2 in the Mozilla/NSS root store.
Thanks,
Ben
|
|
||
Comment 14•2 years ago
|
||
(In reply to Ben Wilson from comment #13)
Hi Kathleen,
Please see my summary of the discussions related to Moudrick's questions and arguments:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/52Gfr4dnJD8/m/AEzVDa0CAwAJ
This is a request to approve Telia's request to include the Telia Root CA v2 in the Mozilla/NSS root store.
Thanks,
Ben
Thanks, Ben! I will proceed with approving this request.
|
|
||
Comment 15•2 years ago
|
||
As per Comment #11, and on behalf of Mozilla I approve this request from Telia Company to include the following root certificate:
** Telia Root CA v2 (Email, Websites)
I will file the NSS bug for the approved changes.
|
|
||
Comment 16•2 years ago
|
||
I have filed bug #1751298 against NSS for the actual changes.
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Updated•1 year ago
|
Description
•