Closed Bug 1172819 Opened 9 years ago Closed 8 years ago

Add OISTE WISeKey Global Root GB CA root certificate

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kblackma, Assigned: kwilson)

References

Details

(Whiteboard: EV - in NSS 3.21, and Firefox 44)

Attachments

(3 files)

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

CA Name: CN = OISTE WISeKey Global Root GB CA, OU = OISTE Foundation Endorsed, O = WISeKey C, = CH
Website: http://www.wisekey.com
One Paragraph Summary of CA, including the following:
 - OISTE (Non Profit Organisation) owns Root CA, run by WISeKey SA (commercial operator)
 - WorldWide

Audit Type (WebTrust, ETSI etc.): WebTrust EV; WebTrust SSL BR; WebTrust CA
Auditor:      Auren
Auditor Website:  http://www.auren.com/
Audit Document URL(s):  https://d3o11irj9639cz.cloudfront.net/uploads/images/WISeKey-WebTrust-Audit-Report-2015.pdf
https://www.wisekey.com/repository

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

Certificate Name: OISTE WISeKey Global Root GB CA
CN = OISTE WISeKey Global Root GB CA, OU = OISTE Foundation Endorsed, O = WISeKey C, = CH¨¨

Summary Paragraph, including the following:
 - End entity certificate issuance policy
The hierarchy will issue a variety of EE certificates: SMIME; Client Authentication; Adobe Signature; SSL; SSL EV; TimeStamp; OCSP; Code Signing
 - Number and type of subordinate CAs
1 Policy CA underneath Root CA  (Root CA issues intermediate CA certificates, and OCSP delegated responder certificate)
3 ACTIVE Issuing CAs underneath Policy CA (Policy CA issues Issuing CA certificates, and OCSP delegated responder certificate)
Issuing CAs issue End Entity certificates of different classes
 - Diagram and/or description of certificate hierarchy
See above.

Certificate download URL (on CA website):  
http://public.wisekey.com/crt/owgrgbca.crt

Version: 3
SHA1 Fingerprint: ‎0f f9 40 76 18 d3 d7 6a 4b 98 f0 a8 35 9e 0c fd 27 ac cc ed
Public key length (for RSA, modulus length) in bits: 2048
Valid From (YYYY-MM-DD): 2014-12-01
Valid To (YYYY-MM-DD): 2039-12-01

CRL HTTP URL:  http://public.wisekey.com/crl/owgrgbca.crl
CRL issuing frequency for subordinate end-entity certificates: every 4 days
CRL issuing frequency for subordinate CA certificates: every month
OCSP URL: http://ocsp.wisekey.com

Class (domain-validated, identity/organizationally-validated or EV): DV, OV, and EV
Certificate Policy URL: https://d3o11irj9639cz.cloudfront.net/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.2-CLEAN.pdf
CPS URL: https://d3o11irj9639cz.cloudfront.net/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.2-CLEAN.pdf
Requested Trust Indicators (email and/or SSL and/or code signing): EMAIL and SSL EV and CODE SIGNING
URL of example website using certificate subordinate to this root
(if applying for SSL):
https://goodssl.wisekey.com    
https://badssl.wisekey.com    (revoked)
https://goodevssl.wisekey.com
https://badevssl.wisekey.com  (revoked)
Mozilla CA Technical Info doc.
I will start the information verification phase for this request soon.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: CN = OISTE WISeKey Global Root GB CA, OU = OISTE Foundation Endorsed, O = WISeKey C, = CH → Add OISTE WISeKey Global Root GB CA root certificate
Regarding:
"SHA-­‐1 Certificates: The main object of this inclusion request is to enable support to SHA-­‐256 in the certificates issued by WISeKey. Once the new root is embedded in the browsers, WISeKey will stop issuing SHA-­‐1 certificates. *We have a quality compromise with our customers to replace any existing SHA-­‐1 SSL certificate with a new equivalent SHA256 certificate before 1-­‐January 2016.*"

Why can't you issue SHA-256 certificates using the old SHA-1 root?

SSL validation in Firefox (and NSS) does not check the signature algorithm of the root certificate. 

Also, note that you could use cross-signing with the old and new root, to help customers migrate to the new CA hierarchy without having to wait for the new root cert to be included in all the major browsers.
Whiteboard: EV - Information Incomplete
I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information.
Additional Requested Information:
Updated CPS covering missing info as per the 1172819-CAInformation.pdf:
Updated CPS v2.3 at: https://www.wisekey.com/repository
OR
https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.3-CLEAN.pdf

Further info:
The main changes are:
•	Included Code Signing Certificates (normal and EV), modified any relevant sections
•	Included the certificate profiles for Code Signing
•	Included the detailed verification methods for SSL and Code Signing certificates.

On Issue:
"NEED CLARIFICATION: I didn't find in the CPS which
forms of verification are used for code signing certificates.
Need Clarification From CA"

In particular, we are including the verification information in annexes C and E. Actually the annex E is an extract of the manual that the enrollment agent must follow, which is written to match exactly the requirements expressed by CABF BR and EV.

On issue
"NEED CLARIFICATION: The CPS should indicate which
forms of verification are acceptable to verify identity,
organization, and authority. etc."

Actually in Annex B we were specifying already that the methods were the ones requested by the CABF, and we though this should be enough… Nevertheless, after your request, we are making reference to the new Annex D mentioned above, which includes explicitly this information, and that of course matches the Baseline and Extended Validation Requirements.
I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: EV - Information Incomplete → EV - Ready for Public Discussion
I am now opening the first public discussion period for this request from WISeKey to include the "OISTE WISeKey Global Root GB CA" root certificate, turn all all three trust bits, and enable EV treatment. 

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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “WISeKey Root Renewal Request”.

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

A representative of WISeKey must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Ready for Public Discussion → EV - In public discussion
The public comment period for this request is now over.

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

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

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

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

Inclusion Policy Section 6 [Relevance and Policy].
WISeKey appears to provide a service relevant to Mozilla users. It provides worldwide eSecurity services based or related to electronic identities and digital certificates. 

The request is to include the "OISTE WISeKey Global Root GB CA" root certificate, turn on all three trust bits, and enable EV treatment.
	  
Root Certificate Name: OISTE WISeKey Global Root GB CA
O From Issuer Field: WISeKey
Requested Trust Bits: Code; Email; Websites
EV Policy OID(s): 2.16.756.5.14.7.4.8
Root Certificate Download URL: http://public.wisekey.com/crt/owgrgbca.crt

Certificate Summary: This SHA-256 root cert will eventually replace WISeKey's SHA-1 root cert that was included in NSS via Bugzilla Bug #371362.

Documents are provided in English.

Document Repository: http://www.wisekey.com/repository
CPS: https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.4-CLEAN.pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
There is currently one Policy CA signed by this SHA-256 root cert, and the one Policy CA currently has three active issuing CAs. 
CA hierarchy diagrams for both the SHA-1 and SHA-256 root certs are provided in section 1.3.1 of the CPS. 
CPS section 1.3.1.2: “OWGTM Policy CA G1” is a Certification Authority subordinated to the “OWGTM Root CA GB”. This CA issue certificates for “Issuing CAs” (Certification Authorities that issue certificates for End Entities) dedicated to specific entities and/or purposes, but this CA itself does not issue certificates to end entities. 
“OWGTM Policy CA G1” can sign: 
- WISeKey Qualified Issuing CAs 
- Partner's Qualified Issuing CAs 
- WISeKey Advanced Issuing CAs 
- Partner's Advanced Issuing CAs 
- WISeKey Standard Issuing CAs 
- Partner's Standard Issuing CAs 
At this moment, there aren’t externally operated SubCAs under the new SHA-256 root, but this is supported as stipulated in WISeKey's CPS. 
For the existing SHA-1 root cert's hierarchy, there’s a limited number of CAs operated by external companies, which enforce name constraints. In particular, the currently active SubCAs are: Government of Seychelles (constrained to *.gov.sc), and The Bancorp Inc. (constrained to *.wise-corp.co, *.thebancorp.com, *.wisecorp.us and *.wise-¬‐ corp.us)


Inclusion Policy Section 7 [Validation]. 
WISeKey appears to meet the minimum requirements for subscriber verification, as follows.

* SSL Verification Procedures: WISeKey confirms that the certificate applicant has control over the domain name(s) to be included in the certificate as described in sections 14.1 and 14.2 of the CPS. 

* Email Verification Procedures: WISeKey confirms that the applicant owns/controls the email address to be included in the certificate as described in section 12.2 of the CPS.

* Code Signing Subscriber Verification Procedure: Section 14.3 of the CPS describes the steps taken to verify the identity of the certificate subscriber, verify the organization, and verify the authority of the certificate subscriber to act on behalf of the organization.

Inclusion Policy Sections 11-14 [Audit].  WISeKey is audited annually according to the WebTrust CA, BR, and EV audit criteria. I have exchanged email with representatives of Auren (the auditor) to confirm the authenticity of the audit statements. 
https://cdn.wisekey.com/uploads/documents/WISeKey-WebTrust-Audit-Report-2015.pdf?6ecb07

Based on this assessment I intend to approve this request from WISeKey to include the "OISTE WISeKey Global Root GB CA" root certificate, turn on all three trust bits, and enable EV treatment.
Whiteboard: EV - In public discussion → EV - Pending Approval
As per the summary in Comment #9, and on behalf of Mozilla I approve this request from WISeKey to include the following root certificate:

** "OISTE WISeKey Global Root GB CA" (websites, email, code signing), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM changes
Depends on: 1213042
Depends on: 1213044
I have filed bug #1213042 against NSS and bug #1213044 against PSM for the actual changes.
Whiteboard: EV - Approved - awaiting NSS and PSM changes → EV - in NSS 3.21, and Firefox 44
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
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

Creator:
Created:
Updated:
Size: