QuoVadis has applied to include the “QuoVadis Root CA 1 G3”, “QuoVadis
Root CA 2 G3”, and “QuoVadis Root CA 3 G3” root certificates, turn on
all three trust bits for the RCA1 and RCA3 root certs, and turn on the
websites and code signing trust bits for the RCA2 root cert. The request
is to also enable EV treatment for the “QuoVadis Root CA 2 G3” root
certificate. These SHA256 root certs will eventually replace the
corresponding QuoVadis root certificates that were included in NSS in
bugs #238381 and #365281.
QuoVadis is a commercial CA serving a global client base, active in both
the markets for SSL and End User certificates with a focus on digital
signatures. The company is a Qualified Certification Services Provider
in Switzerland and Holland, and an issuer in the SuisseID (CH) and PKI
Overheid (NL) eID programmes. QuoVadis serves both enterprises and
individuals.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=926541
And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8403019
Noteworthy points:
* The primary documents, the CP/CPS, are in English.
QuoVadis Document Repository:
https://www.quovadisglobal.com/QVRepository.aspx
RCA1_RCA3_CPS:
https://www.quovadisglobal.com/~/media/Files/Repository/QV_RCA1_RCA3_CPCPS_V4_14.ashx
RCA2_CPS:
https://www.quovadisglobal.com/~/media/Files/Repository/QV_RCA2_CPCPS_v1.14.ashx
* CA Hierarchy: The hierarchy under the new (G3) roots will be very
similar to the hierarchy of the current (G1) roots. CA Hierarchy
diagrams are provided in section 1.3 of RCA1_RCA3_CPS and RCA2_CPS.
** RCA1 and RCA3 share a CP/CPS (RCA1_RCA3_CPS) and are both allowed to
have externally operated subCAs from a policy perspective. However,
QuoVadis concentrates all external subCAs under the RCA3 hierarchy.
Both RCA1 and RCA2 are reserved solely for QuoVadis operated subCAs.
- G3 Roots (i.e. the new roots): Currently the new roots do not have
external subCAs. Any third-party SubCAs added to the G3 hierarchy will
comply with Section 9 of the Mozilla CA Inclusion Policy from inception.
- G1 Roots (i.e. the old roots): Previously, third-party subCAs have
been overseen via contractual controls or technical monitoring,
supported by internal audit. QuoVadis is in the process of
transitioning these clients before May 15, 2014 to either technical
controls (nameConstraints) or audit with public disclosure as specified
in Section 9 of the Mozilla CA Inclusion Policy.
At present, QuoVadis does not expect to have any cross-certificates for
the G3 Root Certificates. However, if QuoVadis needs to start using the
G3 Roots before they have achieved a sufficient level of distribution
amongst the installed base of various software products, they may elect
to issue cross-certificates to the new Roots from the existing QuoVadis
Roots.
* This request is to turn on all three trust bits for the RCA1 and RCA3
root certs, and turn on the websites and code signing trust bits for the
RCA2 root cert.
** Authentication of identity and authority is described in sections
3.2.2 through 3.2.5 of RCA1_RCA3_CPS, and Appendix B of RCA2_CPS.
** RCA1_RCA3_CPS, section 4.1.2: Where Certificates are to be used for
digitally signing and/or encrypting email messages, QuoVadis takes
reasonable measures to verify that the entity submitting the request
controls the email account referenced in the Certificate, or has a legal
right to request a Certificate including the email address. QuoVadis
systems perform a challenge-response procedure by sending an email to
the email address to be included in the Certificate. The Applicant must
respond with a shared secret within a limited time to demonstrate that
they have control over that email address.
** RCA1_RCA3_CPS, section 10.6.1.2, Grid Server Certificate: The
identity vetting of all Applicants must be performed by an approved
Registration Authority (RA). For Grid Server Certificates, the RA must
validate the identity and eligibility of the person in charge of the
specific entities using a secure method. The RA is responsible for
recording, at the time of validation, sufficient information regarding
the Applicant to identify the Applicant. As part of the registration
process the RA must ensure that the Applicant is appropriately
authorised by the owner of the associated Fully Qualified Domain Name
(FQDN) or the responsible administrator of the machine to use the FQDN
identifiers asserted in the Digital Certificate. The RA is responsible
for maintaining documented evidence on retaining the same identity over
time.
The RA must validate the association of the Certificate Signing Request.
The Certificate Request submitted for certification must be bound to the
act of identity vetting.
*** A Grid Server Certificate is used in the for e-Science Grid for
authentication between academic institutions, under standards set by the
EUGridPMA according to the Authentication Profile of the International Grid
Trust Federation (IGTF). The external RA is essentially assisting in the
gathering of supporting documentation - primarily to confirm that the
requestor has the right to use a Grid certificate. As stated in the CPS,
QuoVadis Support approves the Subject and Domain information for all SSL,
and these certificates are issued via our Trust/Link system with the
automated controls to enforce the validation/aging requirements of the BR,
etc.
** RCA1_RCA3_CPS, section 10.7, QuoVadis Device:
***QuoVadis Device Certificates are intended for use in establishing
web-based data communication conduits via TLS/SSL protocols. QuoVadis
Device Certificates (i.e. with the OID 1.3.6.1.4.1.8024.1.600 in
Certificate Policies) that have the Server Authentication Extended Key
Usage comply with the CA/B Forum Baseline Requirements.
***QuoVadis acts as Registration Authority (RA) for Device Certificates
it issues.
Before issuing a Device Certificate, QuoVadis performs procedures to
verify that all Subject information in the Certificate is correct, and
that the Applicant is authorised to use the domain name and/or
Organisation name to be included in the Certificate, and has accepted a
Certificate Holder Agreement for the requested Certificate.
** RCA1_RCA3_CPS section 10.7 and RCA2_CPS section 3.1.7: For each FQDN
listed in a Certificate, QuoVadis confirms that, as of the date the
Certificate was issued, the Applicant either is the Domain Name
Registrant or has control over the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with
the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an
address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the
contact information listed in the WHOIS record’s “registrant”,
“technical”, or “administrative” field;
4. Communicating with the Domain’s administrator using an email address
created by pre-pending ‘admin’, ‘administrator’, ‘webmaster’,
‘hostmaster’, or ‘postmaster’ to the FQDN;
5. Relying upon a Domain Authorization Document; and
6. 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.
** In RCA1_RCA3_CPS the Device certs described in section 10.7 may have
the Code Signing EKU. RCA1_RCA3_CPS section 10.7: Before issuing a
Device Certificate, QuoVadis performs procedures to verify that all
Subject information in the Certificate is correct, and that the
Applicant is authorised to use the domain name and/or Organisation name
to be included in the Certificate, and has accepted a Certificate Holder
Agreement for the requested Certificate.
** RCA2_CPS Appendix B: Before issuing a Code Signing Certificate,
QuoVadis performs limited procedures to verify that all Subject
information in the Certificate is correct, and that the Applicant is
authorised to sign code in the name to be included in the Certificate.
Prior to issuing a Code Signing Certificate to an Organisational
Applicant, QuoVadis:
1. Verifies the Applicant’s possession of the Private Key;
2. Verifies the Subject’s legal identity, including any Doing Business
As (DBA) included in a Certificate,
3. Verifies the Subject’s address, and
4. Verifies the Certificate Requester’s authority to request a
certificate and the authenticity of the Certificate request using a
verified method of communication.
Prior to issuing a Code Signing Certificate to an Individual Applicant,
the QuoVadis:
1. Verifies the Subject’s identity using a government photo ID,
2. Verifies the Subject’s address using reliable data sources,
3. Obtains a biometric associated with the Subject, such as a
fingerprint or notarized handwritten Declaration of Identity,
4. Verifies the Certificate Requester’s authority to request a
certificate and the authenticity of the Certificate request using a
verified method of communication.
** RCA2_CPS Appendix B: Before issuing an EV Certificate, QuoVadis
ensures that all Subject organisation information in the EV Certificate
conforms to the requirements of, and has been verified in accordance
with, the EV Guidelines and matches the information confirmed and
documented by the CA pursuant to its verification processes. Such
verification processes are intended to accomplish the following:
i. Verify Applicant’s existence and identity, including;
- Verify Applicant’s legal existence and identity (as established with
an Incorporating Agency),
- Verify Applicant’s physical existence (business presence at a physical
address), and
- Verify Applicant’s operational existence (business activity).
ii. Verify Applicant (or a corporate parent/subsidiary) is a registered
holder or has exclusive control of the domain name to be included in the
EV Certificate;
iii. Verify Applicant’s authorization for the EV Certificate, including;
- Verify the name, title, and authority of the Contract Signer,
Certificate Approver, and Certificate Requester;
- Verify that Contract Signer signed the Certificate Holder Agreement; and
- Verify that a Certificate Approver has signed or otherwise approved
the EV Certificate Request.
* EV Policy OID: 1.3.6.1.4.1.8024.0.2.100.1.2
** EV treatment is only requested for RCA2.
* Root Cert URLs
http://trust.quovadisglobal.com/qvrca1g3.crt
http://trust.quovadisglobal.com/qvrca2g3.crt
http://trust.quovadisglobal.com/qvrca3g3.crt
* Test Websites
https://qvica1g3-v.quovadisglobal.com
https://evsslicag3-v.quovadisglobal.com
https://qvica3g3-v.quovadisglobal.com
http://www.quovadisglobal.com/en-GB/QVRepository/TestCertificates.aspx
* CRL
http://crl.quovadisglobal.com/qvrca1g3.crl
http://crl.quovadisglobal.com/qvrca2g3.crl
http://crl.quovadisglobal.com/qvrca3g3.crl
* OCSP
http://ocsp.quovadisglobal.com
* Audit: Annual audits are performed by Ernst & Young according to the
WebTrust criteria.
WebTrust for CAs: https://cert.webtrust.org/SealFile?seal=1503&file=pdf
WebTrust for EV: https://cert.webtrust.org/SealFile?seal=1508&file=pdf
WebTrust for BRs: https://cert.webtrust.org/SealFile?seal=1520&file=pdf
Ernst & Young auditors were present for the creation ceremony for the G3
Roots.
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** CPS allows for external subCAs, but any external subCAs that are
added to the G3 hierarchy will comply with Section 9 of Mozilla’s CA
Inclusion Policy from inception.
** QuoVadis has issued OV SSL (never EV) referencing internal server
names, and has implemented procedures to deprecate their use in line
with the Baseline Requirements. See Section 3.1.1 of the CP/CPS for
Root CA2. QuoVadis communicates the risks of such practices with
customers, and such requests are approved by a QuoVadis Administrator
before issuance. QuoVadis will not issue SSL including internal server
names with an Expiry Date later than November 1, 2015. Effective 1
October 2016, QuoVadis will revoke any unexpired SSL whose CN or SAN
contains internal server names.
** External RAs may be used in all three hierarchies. However, in the
case of SSL certificates, external RAs may only assist in the gathering
of validation information. QuoVadis provides signoff and acts as the
actual RA for all SSL requests.
*** External RAs:
QV_RCA2_CPCPS_v1.13.ashx: Client Local RAs can issue Business SSL and EV
SSL for Oganizations and Domains that have be pre-authentiated by QuoVadis.
QV_RCA1_RCA3_CPCPS_V4_13.ashx section 1.3.2: Registration Authorities
must perform certain functions in accordance with this CP/CPS and
applicable Registration Authority Agreement which include but are not
limited to;
- Process all Digital Certificate application requests.
- Maintain and process all supporting documentation related to Digital
Certificate applications.
- Process all Digital Certificate Revocation requests.
- Comply with the provisions of its QuoVadis Registration Authority
Agreement and the provisions of this QuoVadis CP/CPS including, without
limitation to the generality of the foregoing, compliance with any
compliance audit requirements.
- Follow a privacy policy in accordance with this CP/CPS and the
applicable Registration Authority Agreement.
This begins the discussion of the request from QuoVadis to include the
“QuoVadis Root CA 1 G3”, “QuoVadis Root CA 2 G3”, and “QuoVadis Root CA
3 G3” root certificates, turn on all three trust bits for the RCA1 and
RCA3 root certs, and turn on the websites and code signing trust bits
for the RCA2 root cert. The request is to also enable EV treatment for
the “QuoVadis Root CA 2 G3” root certificate.
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
