WISeKey has applied to include the "OISTE WISeKey Global Root GB CA"
root certificate, turn all all three trust bits, and enable EV
treatment. This SHA-256 root cert will eventually replace WISeKey's
SHA-1 root cert that was included in NSS via Bugzilla Bug #371362.
WISeKey provides worldwide eSecurity services based or related to
electronic identities and digital certificates. There’s no focus on a
particular region or customer profile.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1172819
And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8640737
Noteworthy points:
* Documents are provided in English.
CA Document Repository: http://www.wisekey.com/repository
CPS:
https://cdn.wisekey.com/uploads/images/WKPKI.DE001-OWGTM-PKI-CPS.v2.3-CLEAN.pdf
* CA 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)
* This request is to turn on all three trust bits, and to enable EV
treatment.
** CPS section 3.2.2, 3.2.3, 3.2.5: This information is specified in
Annex C: Identity Validation Policies
CPS section 12 == Annex C
** CPS section 12.2.1 -- Personal Certificates
Standard -- ID Data Verified: Basic data is verified such as the email
address; or in the case of an organisation ownership of the domain names
in the certificate, with responsibility to verify the individual
entities to which certificates are issued.
Method of Verification:
- Bounce back email verification procedure proving access to the email
account is accepted.
- Database (such as existing HR, or IDM) of organisation, with details
of organisation's users.
- Commonly accepted business methods of identity verification.
Advanced -- May be done through database of identity data that is well
maintained and was created based on face to face or direct verification
using official ID documents.
Qualified -- Face to face or direct verification but may be done through
database of identity data that is well-maintained and was created based
on face to face or direct verification using primary ID documents.
** CPS section 12.2.2:
CertifyID Standard SSL Certificate: The identification data included in
the certificate are verified according to the Baseline Requirements made
public by the CA/Browser Forum.
(For more information, see section 14 "Annex E: Notes on validation
methods for SSL and Code Signing certificates")
** CPS section 12.2.2:
CertifyID Advanced EV SSL Certificate: The identification data included
in the certificate are verified according to the Baseline Requirements
made public by the CA/Browser Forum.
(For more information, see section 14 "Annex E: Notes on validation
methods for SSL and Code Signing certificates")
** CPS section 12.2.4:
CertifyID Code Signing and CertifyID EV Code Signing Certificates: The
identification data included in the certificate are verified
according to the Extended Validation Requirements made public by the
CA/Browser Forum.
(For more information, see section 14 “Annex E: Notes on validation
methods for SSL and Code Signing certificates”)
** CPS section 14.1.2 and 14.2.2
For the Fully-Qualified Domain Name listed as SAN in a Certificate, the
Agent shall confirm that, as of the date the Certificate was issued, the
Applicant either is the Domain Name Registrant or has control
over the FQDN by any of the following:
1. Communicating directly with the Domain Name Registrant using the
contact information listed in
the WHOIS record’s “registrant”, “technical”, or “administrative” field;
2. Communicating with the Domain’s administrator using an email address
created by pre-pending
‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in
the local part, followed by
the at-sign (“@”), followed by the Domain Name, which may be formed by
pruning zero or more
components from the requested FQDN;
3. Relying upon a Domain Authorization Document (See Note); or
4. Having the Applicant demonstrate practical control over the FQDN by
making an agreed-upon change to information found on an online Web page
identified by a uniform resource identifier containing the FQDN.
Note: If the CA relies upon a Domain Authorization Document to confirm
the Applicant’s control over a FQDN, then the Domain Authorization
Document MUST substantiate that the communication came from either the
Domain Name Registrant (including any private, anonymous, or proxy
registration service) or the Domain Name Registrar listed in the WHOIS.
** CPS section 14.4 - Verification process for CertifyID
Code Signing Certificates
*** CPS section 14.4.1.2 -- Verification of Individual Identity
If an individual requests the certificate, the Agent must request a
proof of Identity to accompany the certificate request. The accepted
method requires receiving a copy of a National ID, Drivers License or
Passport.
*** CPS section 14.4.1.3 -- Verification of Organization Identity
If the organization name is present in the certificate, the Agent must
verify the identity of the Applicant using documentation provided by, or
through communication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant’s legal
creation, existence, or recognition (i.e. chamber of commerce, official
commerce registry...);
2. A third party database that is periodically updated and considered a
Reliable Data Source;
3. A site visit by the Agent; or
4. An Attestation Letter.
* EV Policy OID: 2.16.756.5.14.7.4.8
* Root Cert URL: http://public.wisekey.com/crt/owgrgbca.crt
* Test Website: https://goodevssl.wisekey.com/
* CRL: http://public.wisekey.com/crl/owgrgbca.crl
http://public.wisekey.com/crl/wcidpgbca1.crl
http://public.wisekey.com/crl/wcidagbca2.crl
* OCSP: http://ocsp.wisekey.com/
http://ocsp2.wisekey.com
* Audit: WISeKey is audited annually according to the WebTrust audit
criteria. I have exchanged email with representatives of Auren (the
auditor) to confirm the authenticity of the audit statement.
https://cdn.wisekey.com/uploads/documents/WISeKey-WebTrust-Audit-Report-2015.pdf?6ecb07
* Potentially Problematic Practices -- None noted
(http://wiki.mozilla.org/CA:Problematic_Practices)
This begins the discussion of the request from WISeKey to include the
"OISTE WISeKey Global Root GB CA" root certificate, turn all all three
trust bits, and enable EV treatment.
At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
