Closed Bug 539924 Opened 15 years ago Closed 10 years ago

Add TeliaSonera Root CA v1 root certificate

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: janne.m.k, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: Approved - in FF 29)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: 

CA Company/Organization Name: TeliaSonera

Website: http://www.teliasonera.com/home

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

TeliaSonera provides telecommunication services in the Nordic and Baltic countries, the emerging markets of Eurasia, including Russia and Turkey, and in Spain. CA operations currently only in Nordic countries.

Number and type of subordinate CAs: 5 Subordinate CA's for server, client, email and vpn certificates 

Audit Type (WebTrust, ETSI etc.): WebTrust

Auditor: Ernst & Young

Auditor Website: http://www.ey.com/GL/EN/Home

Audit Document URL(s): https://cert.webtrust.org/ViewSeal?id=564

Certificate Name: TeliaSonera Root CA v1

Summary Paragraph, including the following: 
End entity certificate issuance policy, i.e. what you plan to do with the root 
Diagram and/or description of certificate hierarchy:

TeliaSonera root CA v1 issued subordinate CA's mentionded below. Subordinate CA's will issue end entity certificates for types stated in sub CA names.

Number and type of subordinate CAs: 5 Subordinate CA's for server, client, email and vpn certificates 

List or description of subordinate CAs operated internally: 
TeliaSonera Class1 CA v1 (smart card / usb token based client certificates)
TeliaSonera Class2 CA v2 (software client certificates)
TeliaSonera Server CA v1
TeliaSonera Email CA v3
TeliaSonera VPN CA v1

List or description of subordinate CAs operated by third parties: -

List root CAs that have issued cross-signing certificates for this root CA 
Certificate HTTP download URL (on CA website): - 

Version: V3

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: RSA 4096 bits

Valid From (YYYY-MM-DD): 2007-10-18

Valid To (YYYY-MM-DD): 2032-10-18

CRL HTTP URL: http://crl-2.trust.teliasonera.com/teliasonerarootcav1.crl

CRL issuing frequency for end-entity certificates: Varies between subordinate CA's (1-2 hours)

OCSP URL: - 

Class (domain-validated, identity/organisationally-validated or EV): Domain & Organization validation

EV policy OID(s) (if applicable): - 

Certificate Policy URL: -

CPS URL: http://support.partnergate.sonera.com/download/CA/TeliaSonera_Root_CA_v1_CPS%20Rev_A.pdf

List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): (SSL/TLS)and Email (S/MIME)

URL of website whose SSL certificate chains to this root (if applying for SSL): Currently unavailable. We will create such a website soon.



Reproducible: Always
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
Whiteboard: Information incomplete
At last we are ready to complete this root addition request. All requirements should be now OK. For clarity I refill all topics because many items have changed since the original request.

CA Company/Organization Name: TeliaSonera

Website: http://www.teliasonera.com

One Paragraph Summary of CA Company/Organization, including the following: 
General nature (e.g., commercial, government, academic/research, nonprofit) 
Primary geographical area(s) served: 
TeliaSonera provides telecommunication services in the Nordic and Baltic countries, the emerging markets of Eurasia, including Russia and Turkey, and in Spain. CA operations currently only in Nordic countries.

Number and type of subordinate CAs: 6 Subordinate CA's for server, client and TeliaSonera internal certificates.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Ernst & Young
Auditor Website: http://www.ey.com/GL/EN/Home
Audit Document URL(s): https://cert.webtrust.org/ViewSeal?id=1369

Certificate Name: TeliaSonera Root CA v1

Summary Paragraph, including the following: 
End entity certificate issuance policy, i.e. what you plan to do with the root 
Diagram and/or description of certificate hierarchy: TeliaSonera root CA v1 has issued subordinate CA's mentionded below. Subordinate CA's will 
issue end entity certificates for types stated in sub CA names.

Number and type of subordinate CAs: 6 Subordinate CA's for server, client and TeliaSonera internal certificates 

List or description of subordinate CAs operated internally: 
TeliaSonera Class1 CA v1 (public client certificates issued in Finland)
TeliaSonera Class2 CA v1 (public client certificates issued in Sweden)
TeliaSonera Server CA v1 (public SSL certificates)
TeliaSonera Gateway CA v1 (internal SSL server certificates for TeliaSonera services)
TeliaSonera Email CA v3 (internal client certificates for TeliaSonera internal email system)
TeliaSonera Mobile ID CA v1 (internal mobile certificates for TeliaSonera mobile phone services) 

List or description of subordinate CAs operated by third parties: -

List root CAs that have issued cross-signing certificates for this root CA: 
Sonera Class2 CA

Certificate HTTP download URL (on CA website): http://repository.trust.teliasonera.com/teliasonerarootcav1.cer

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: RSA 4096 bits
Valid From (YYYY-MM-DD): 2007-10-18
Valid To (YYYY-MM-DD): 2032-10-18

CRL HTTP URL: 
http://crl-2.trust.teliasonera.com/teliasonerarootcav1.crl
http://crl-3.trust.teliasonera.com/teliasonerarootcav1.crl

CRL issuing frequency for end-entity certificates: Varies between subordinate CA's (1-2 hours)

OCSP URL: http://ocsp.trust.teliasonera.com 

Class (domain-validated, identity/organisationally-validated or EV): Domain & identity/organization validated

EV policy OID(s) (if applicable): - 

Certificate Policy URL: http://repository.trust.teliasonera.com/TeliaSonera_Root_CPS_v2.01.pdf
CPS URL: http://repository.trust.teliasonera.com/TeliaSonera_Root_CPS_v2.01.pdf
CPS site for public sub CAs is this: http://repository.trust.teliasonera.com or http://support.partnergate.sonera.com/cavarmenne_en.html
Internal Mobile ID certificate CPS is available only in Finnish at: http://repository.trust.teliasonera.com/mobile-id

List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): (SSL/TLS)and Email (S/MIME)

URL of website whose SSL certificate chains to this root (if applying for SSL): https://juolukka.cover.sonera.net:10443/

Reproducible: Always

Answers to questions on the form: https://bug539924.bugzilla.mozilla.org/attachment.cgi?id=422810

The audit includes “TeliaSonera Root CA v1” and its subordinate CAs including “TeliaSonera Class 2 CA v1 and
TeliaSonera E-mail CA v3”. 
What about the other sub-CAs, e.g. Class1, Server, and VPN?
What’s the difference between “TeliaSonera Class 2 CA v1” and “TeliaSonera Class2 CA v2” that is listed as one of the 5
sub-CAs for this root above?
ANSWER: The new audit report list all sub-CAs. The inactive ones were unnecessary to audit (We'll activate those soon).
One (TeliaSonera Mobile ID CA v1) was out of Webtrust scope because it is only in internal use of TeliaSonera systems.

It is not clear to me how TeliaSonera verifies that the certificate subscriber owns/controls the domain name to be
included in the certificate. E.g. how is the information obtained from the third party used to do the verification?
I may misunderstand, but it appears that once Registration Officer of a Customer Organization is approved, then
that Registration Officer can approve and issue SSL certificates. Correct? How is it controlled which domains the
Registration Officer issues SSL certs for?
ANSWER: We have rewritten all CPS/Policy documents to be clearer. Verification process is described in chapter 
3.2.2 (Authentication of organization identity) in the new Server certificate CPS and policy. In enterprise RA cases when 
Customer Registration Officer is allowed to enroll server certificates for his/her organization each organization 
and domain value is first inspected by TeliaSonera Registration Officer using the documented checking rules. Then the values 
are added to the configuration of that customer so that later the customer can use same values without a new verification.

Please review the list of Potentially Problematic Practices (http://wiki.mozilla.org/CA:Problematic_Practices).
Identify the ones that are and are not applicable. For the ones that are applicable, please provide further
information and pointers to the relevant sections of the CP/CPS documents.
 Long-lived DV certificates
o We have always organization validation also (check CPS 3.2.2). We have maximum validity time of three years. After that normal 
customers have to provide SSL order again and everything is re-checked. In Enterprise RA case we have improvement
idea to redo domain checks periodically. We have already added a timestamp on each approved value in our database. 
Because of that it is easy to find expiring values.

 Wildcard DV SSL certificates
o We have always organization validation also (check Server CPS 3.2.2).

 Delegation of Domain / Email validation to third parties
o Not applicable. We do all domain/email validation ourselves.

 Issuing end entity certificates directly from roots
o We are stopping this problematic practice during this year when our new TeliaSonera CAs are replacing the old Sonera CAs.

 Allowing external entities to operate unconstrained subordinate CAs
o Not applicable. All Sub CAs are operated by TeliaSonera.

 Distributing generated private keys in PKCS#12 files
o Only applicable with some client certificates. When applicable the PKCS#12 file is always PIN protected and 
transferred using TLS/SSL protected channel. Check 6.1.2 in TeliaSonera Organizational User Certificate Policy and CPS.

 Certificates referencing hostnames or private IP addresses
o We will stop enrolling these in the schedule that Cab BR 9.2.1 has specified.

 Issuing SSL Certificates for Internal Domains
o Not applicable. .int is not used and it is considered as valid public suffix. Null character domain values are 
automatically discarded. We have our own list of valid TLD values. We are not using internal domain names in our internal CAs
in the same CA hierarchy.

 OCSP Responses signed by a certificate under a different root
o Not applicable. Our upcoming OCSP service (live in November 2012) is using the same CA/root as the SSL certificate.

 CRL with critical CIDP Extension
o Not applicable. CRLs downloaded into Firefox without error.

 Generic names for CAs
o Not applicable. Root cert name is not generic.
Please confirm that the information in the attached document is complete and correct.

Also, please update this bug when your OCSP service is available, and the test website has been updated with an SSL cert that includes the OCSP URI in the AIA.
I confirm that the attachment 677798 [details] is correct. OCSP is now enabled and our SSL test site is using it via AIA. 
Firefox has been tested to work correctly with the test site. Note! OCSP is only used on server certificates and not on client or CA certificates.
Whiteboard: Information incomplete → Information confirmed complete
I am now opening the first public discussion period for this request from TeliaSonera to add the “TeliaSonera Root CA v1” root certificate and enable the websites and email trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

The discussion thread is called “TeliaSonera Request to included Renewed Root”

Please actively review, respond, and contribute to the discussion.

A representative of TeliaSonera must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “TeliaSonera Root CA v1” root certificate and enable the websites and email trust bits.

Section 4 [Technical]. I am not aware of instances where TeliaSonera has knowingly issued certificates for fraudulent use. If anyone knows of any such instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. The TeliaSonera CA appears to provide a service relevant to Mozilla users:  It issues certificates in Finland and Sweden, and may expand their CA business into other countries that are registered in the European Economic Area (EEA) which comprises the countries of the European Union (EU), plus Iceland, Liechtenstein and Norway.

The main documents of interest are the CPS documents that are provided in English at the following website.

Repository: https://repository.trust.teliasonera.com

Section 7 [Validation]. TeliaSonera appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: Verification of domain ownership/control is specified in section 3.2 of the TeliaSonera Server Certificate CPS. TeliaSonera verifies domain names and IP addresses from a database maintained by a reliable third party registrar e.g. “domain.fi” (for domain “.fi”), iis.se (for domain “.se”), ripe.net (for IP addresses) and www.networksolutions.com/whosis-search (for non-country domains), that as of the date the Certificate was issued, the Aplication either had the right to use, or had control of, the Fully-Qualified Domain Names(s) and IP address(es) listed in the Certificate, or was authorized by a person having such right or control (e.g. under a Principal-Agent or Licensor-Licensee relationship) to obtain a Certificate Containing the Fully-Qualfiied Domain mames(s) and IP address(es).
In enterprise RA cases when Customer Registration Officer is allowed to enroll server certificates for his/her organization each organization and domain value is first inspected by TeliaSonera Registration Officer using the documented checking rules. Then the values are added to the configuration of that customer so that later the customer can use same values without a new verification

* Email: Section 3.2 of the TeliaSonera Organizational User Certificate CPS describes the steps to verify that the certificate subscriber owns/controls the email address to be included in the certificate. TeliaSonera verifies the ownership of an email address by sending a one-time-password to the applied email-address. Then the Subject entity must use the password within limited time frame to prove the access to the email-address. In Enterprise RA cases email-address can be taken from reliable internal source of the Subscriber without additional verification by one-time-password.

* Code: Not applicable. Not requesting the code signing trust bit. 

Section 8-10 [Audit].  Annual WebTrust audits are performed by Ernst & Young and posted on the webtrust.org website.
https://cert.webtrust.org/ViewSeal?id=1369 

Section 15 [Certificate Hierarchy]. This root cert has 6 internally-operated subordinate CAs for server, client, and TeliaSonera internal certificates

* CRL
http://crl-2.trust.teliasonera.com/teliasonerarootcav1.crl 
http://crl-3.trust.teliasonera.com/teliasonerarootcav1.crl (NextUpdate: 7 days)
TeliaSonera Root CPS Section 4.9.7: CRLs are published at least once in a day. The CRL validity period is 168 hours. (7 days)

* OCSP: http://ocsp.trust.teliasonera.com/

Based on this assessment I intend to approve this request to add the “TeliaSonera Root CA v1” root certificate and enable the websites and email trust bits.

Note: Approval is pending the new audit statement.
Whiteboard: In public discussion → Pending current audit statement and Approval
(In reply to Kathleen Wilson from comment #7)
>
> Note: Approval is pending the new audit statement.

https://cert.webtrust.org/SealFile?seal=1576&file=pdf
As per the summary in Comment #7, and on behalf of Mozilla I approve this request from TeliaSonera to include the following root certificate:

** "TeliaSonera Root CA v1" (websites, email)

I will file the NSS bug for the approved changes.
Whiteboard: Pending current audit statement and Approval → Approved - awaiting NSS
Depends on: 925412
I have filed bug #925412 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → Approved - in FF 29
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: