Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
QuoVadis Request to Include Renewed Roots
491 views
Skip to first unread message
Kathleen Wilson
Apr 7, 2014, 8:42:53 PM4/7/14
to mozilla-dev-s...@lists.mozilla.org
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
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
Kathleen Wilson
Apr 24, 2014, 4:16:20 PM4/24/14
to mozilla-dev-s...@lists.mozilla.org
On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
> 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.
>
Does anyone have any questions or comments about this request from QuoVadis?
> 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.
>
Kathleen
Kathleen Wilson
May 6, 2014, 7:21:48 PM5/6/14
to mozilla-dev-s...@lists.mozilla.org
On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
> On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
>> QuoVadis has applied to include the �QuoVadis Root CA 1 G3�, �QuoVadis
> On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
>> 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
>> websites and code signing trust bits for the RCA2 root cert. The request
>> certificate. These SHA256 root certs will eventually replace the
>> corresponding QuoVadis root certificates that were included in NSS in
>> bugs #238381 and #365281.
>>
>
> Does anyone have any questions or comments about this request from
> QuoVadis?
>
> Kathleen
>
>
Should I take the lack of input on this request to mean that everyone is
>> corresponding QuoVadis root certificates that were included in NSS in
>> bugs #238381 and #365281.
>>
>
> Does anyone have any questions or comments about this request from
> QuoVadis?
>
> Kathleen
>
>
OK with it?
Or does it just mean that folks need more time to consider this request?
Thanks,
Kathleen
Chema López
May 9, 2014, 3:05:38 AM5/9/14
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
" 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."
Are they asking for the same bits/CA that they already had with the
on the websites and code signing trust bits for the RCA2 root cert."
precious CAs?
Maybe this is not the adequate forum but have they consider Microsoft new
requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
?
"
*Separation of SSL and Code Signing Key Uses*
Intermediate CA certificates under root certificates submitted for
distribution by the Program must be configured to separate server
authentication (SSL) from code signing and time stamping uses. A single
issuing CA must not be used to issue both server authentication and code
signing certificates.
"
BR
m...@chemalogo.com
+34 666 429 224 (Spain)
gplus.to/chemalogo
@chemalogo <https://twitter.com/chemalogo/>
www.linkedin.com/in/chemalogo
Skype: chemalogo
On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>
> Should I take the lack of input on this request to mean that everyone is
> OK with it?
> Or does it just mean that folks need more time to consider this request?
>
> Thanks,
>
> Kathleen
>
> _______________________________________________
> OK with it?
> Or does it just mean that folks need more time to consider this request?
>
> Thanks,
>
> Kathleen
>
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Stephen Davidson
May 12, 2014, 9:31:45 AM5/12/14
to Chema López, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
QuoVadis is compliant with the Microsoft requirements, and has implemented separate SHA256 intermediate CAs for the issuance of code signing certificates. (More precisely stated, QuoVadis SSL certificates are not issued from the same intermediate CAs as time stamping and code signing certificates).
Kind regards, Stephen Davidson
QuoVadis
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Chema López
Sent: Friday, May 09, 2014 4:06 AM
To: Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: QuoVadis Request to Include Renewed Roots
" 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."
Kind regards, Stephen Davidson
QuoVadis
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Chema López
Sent: Friday, May 09, 2014 4:06 AM
To: Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: QuoVadis Request to Include Renewed Roots
" 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."
Are they asking for the same bits/CA that they already had with the precious CAs?
Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
?
"
*Separation of SSL and Code Signing Key Uses*
Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
"
BR
m...@chemalogo.com
+34 666 429 224 (Spain)
gplus.to/chemalogo
@chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
Skype: chemalogo
On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>
Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
?
"
*Separation of SSL and Code Signing Key Uses*
Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
"
BR
m...@chemalogo.com
+34 666 429 224 (Spain)
gplus.to/chemalogo
@chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
Skype: chemalogo
On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>
fhw...@gmail.com
May 14, 2014, 8:54:09 AM5/14/14
to mozilla-dev-s...@lists.mozilla.org
By my reading of the Microsoft requirements using separate intermediates is insufficient: they must be root certificates.
I'm not familiar with their reasoning behind that but I can imagine cases where that could be a good idea (a consequence of Heartbleed perhaps). Whatever the case may be, if you're going to have the rule then some enforcement mechanism is necessary hence the need for a code-signing-only cert in the trust store.
I also would like to see an official statement regarding when the current QuoVadis certs in the trust store may be removed. We should require a time certain for when the "replaced certs" should be considered obsolete and thus revoked via removal.
Original Message
From: Stephen Davidson
Sent: Monday, May 12, 2014 8:32 AM
To: Chema López; Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: RE: QuoVadis Request to Include Renewed Roots
QuoVadis is compliant with the Microsoft requirements, and has implemented separate SHA256 intermediate CAs for the issuance of code signing certificates. (More precisely stated, QuoVadis SSL certificates are not issued from the same intermediate CAs as time stamping and code signing certificates).
Kind regards, Stephen Davidson
QuoVadis
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Chema López
Sent: Friday, May 09, 2014 4:06 AM
To: Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: QuoVadis Request to Include Renewed Roots
I'm not familiar with their reasoning behind that but I can imagine cases where that could be a good idea (a consequence of Heartbleed perhaps). Whatever the case may be, if you're going to have the rule then some enforcement mechanism is necessary hence the need for a code-signing-only cert in the trust store.
I also would like to see an official statement regarding when the current QuoVadis certs in the trust store may be removed. We should require a time certain for when the "replaced certs" should be considered obsolete and thus revoked via removal.
Original Message
From: Stephen Davidson
Sent: Monday, May 12, 2014 8:32 AM
To: Chema López; Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: RE: QuoVadis Request to Include Renewed Roots
QuoVadis is compliant with the Microsoft requirements, and has implemented separate SHA256 intermediate CAs for the issuance of code signing certificates. (More precisely stated, QuoVadis SSL certificates are not issued from the same intermediate CAs as time stamping and code signing certificates).
Kind regards, Stephen Davidson
QuoVadis
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Chema López
Sent: Friday, May 09, 2014 4:06 AM
To: Kathleen Wilson
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: QuoVadis Request to Include Renewed Roots
" 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."
Are they asking for the same bits/CA that they already had with the precious CAs?
Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
?
"
*Separation of SSL and Code Signing Key Uses*
Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
"
BR
m...@chemalogo.com
+34 666 429 224 (Spain)
gplus.to/chemalogo
@chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
Skype: chemalogo
On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>
Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
?
"
*Separation of SSL and Code Signing Key Uses*
Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
"
BR
m...@chemalogo.com
+34 666 429 224 (Spain)
gplus.to/chemalogo
@chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
Skype: chemalogo
On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>
Rob Stradling
May 14, 2014, 9:07:25 AM5/14/14
to fhw...@gmail.com, mozilla-dev-s...@lists.mozilla.org
On 14/05/14 13:54, fhw...@gmail.com wrote:
> By my reading of the Microsoft requirements using separate intermediates is insufficient: they must be root certificates.
Peter, my reading of the Microsoft requirements [1] is that using
> By my reading of the Microsoft requirements using separate intermediates is insufficient: they must be root certificates.
separate intermediates is sufficient (although note the EKU requirement
for non-legacy intermediates).
"INTERMEDIATE / ISSUING CA CERTIFICATES
...
Separation of SSL and Code Signing Key Uses
Intermediate CA certificates under root certificates submitted for
distribution by the Program must be configured to separate server
authentication (SSL) from code signing and time stamping uses. A single
issuing CA must not be used to issue both server authentication and code
signing certificates.
Rollover root certificates will not be accepted that combine server
distribution by the Program must be configured to separate server
authentication (SSL) from code signing and time stamping uses. A single
issuing CA must not be used to issue both server authentication and code
signing certificates.
authentication with code signing uses unless the uses are separated by
application of EKUs at the intermediate CA certificate level that are
reflected in the whole certificate chain."
[1]
http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx
> I'm not familiar with their reasoning behind that but I can imagine cases where that could be a good idea (a consequence of Heartbleed perhaps). Whatever the case may be, if you're going to have the rule then some enforcement mechanism is necessary hence the need for a code-signing-only cert in the trust store.
>
> I also would like to see an official statement regarding when the current QuoVadis certs in the trust store may be removed. We should require a time certain for when the "replaced certs" should be considered obsolete and thus revoked via removal.
>
>
> Original Message
> From: Stephen Davidson
> Sent: Monday, May 12, 2014 8:32 AM
> To: Chema López; Kathleen Wilson
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: RE: QuoVadis Request to Include Renewed Roots
>
> QuoVadis is compliant with the Microsoft requirements, and has implemented separate SHA256 intermediate CAs for the issuance of code signing certificates. (More precisely stated, QuoVadis SSL certificates are not issued from the same intermediate CAs as time stamping and code signing certificates).
>
> Kind regards, Stephen Davidson
> QuoVadis
>
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+s.davidson=quovadisg...@lists.mozilla.org] On Behalf Of Chema López
> Sent: Friday, May 09, 2014 4:06 AM
> To: Kathleen Wilson
> Cc: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: QuoVadis Request to Include Renewed Roots
>
> " 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."
>
>
> Are they asking for the same bits/CA that they already had with the precious CAs?
>
> Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
> ?
> "
>
> *Separation of SSL and Code Signing Key Uses*
>
> Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
> "
>
> BR
>
> m...@chemalogo.com
> +34 666 429 224 (Spain)
> gplus.to/chemalogo
> @chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
> Skype: chemalogo
>
>
> On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>
>> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>>
>
> Maybe this is not the adequate forum but have they consider Microsoft new requirements<http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx>
> ?
> "
>
> *Separation of SSL and Code Signing Key Uses*
>
> Intermediate CA certificates under root certificates submitted for distribution by the Program must be configured to separate server authentication (SSL) from code signing and time stamping uses. A single issuing CA must not be used to issue both server authentication and code signing certificates.
> "
>
> BR
>
> m...@chemalogo.com
> +34 666 429 224 (Spain)
> gplus.to/chemalogo
> @chemalogo <https://twitter.com/chemalogo/> www.linkedin.com/in/chemalogo
> Skype: chemalogo
>
>
> On Wed, May 7, 2014 at 1:21 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>
>> On 4/24/14, 1:16 PM, Kathleen Wilson wrote:
>>
>> Should I take the lack of input on this request to mean that everyone
>> is OK with it?
>> Or does it just mean that folks need more time to consider this request?
>>
>> Thanks,
>>
>> Kathleen
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
>> is OK with it?
>> Or does it just mean that folks need more time to consider this request?
>>
>> Thanks,
>>
>> Kathleen
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
fhw...@gmail.com
May 14, 2014, 9:42:38 AM5/14/14
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org
Thanks for pointing out my oversight, Rob. When I read that first paragraph I skipped over the first word, which is an important first word!
I was a little thrown by the last sentence, "a single issuing CA". I took that to mean root cert, but I guess they meant any intermediate within the chain?
Does anyone have insight into why Microsoft wants to do this? Without the enforcement this is just a "you have to promise not to do this" and "okay we won't" situation. I don't see any point in that.
Original Message
From: Rob Stradling
Sent: Wednesday, May 14, 2014 8:07 AM
To: fhw...@gmail.com; mozilla-dev-s...@lists.mozilla.org
> QuoVadis
I was a little thrown by the last sentence, "a single issuing CA". I took that to mean root cert, but I guess they meant any intermediate within the chain?
Does anyone have insight into why Microsoft wants to do this? Without the enforcement this is just a "you have to promise not to do this" and "okay we won't" situation. I don't see any point in that.
Original Message
From: Rob Stradling
Sent: Wednesday, May 14, 2014 8:07 AM
To: fhw...@gmail.com; mozilla-dev-s...@lists.mozilla.org
Subject: Re: QuoVadis Request to Include Renewed Roots
Kathleen Wilson
May 29, 2014, 3:53:30 PM5/29/14
to mozilla-dev-s...@lists.mozilla.org
On 5/14/14, 6:42 AM, fhw...@gmail.com wrote:
> Thanks for pointing out my oversight, Rob. When I read that first paragraph I skipped over the first word, which is an important first word!
>
> I was a little thrown by the last sentence, "a single issuing CA". I took that to mean root cert, but I guess they meant any intermediate within the chain?
>
> Does anyone have insight into why Microsoft wants to do this? Without the enforcement this is just a "you have to promise not to do this" and "okay we won't" situation. I don't see any point in that.
>
By the way, these 3 new roots were included into Microsoft's program
> Thanks for pointing out my oversight, Rob. When I read that first paragraph I skipped over the first word, which is an important first word!
>
> I was a little thrown by the last sentence, "a single issuing CA". I took that to mean root cert, but I guess they meant any intermediate within the chain?
>
> Does anyone have insight into why Microsoft wants to do this? Without the enforcement this is just a "you have to promise not to do this" and "okay we won't" situation. I don't see any point in that.
>
last August.
http://social.technet.microsoft.com/wiki/contents/articles/19218.windows-and-windows-phone-8-ssl-root-certificate-program-august-2013.aspx
Kathleen
Kathleen Wilson
May 29, 2014, 4:15:21 PM5/29/14
to mozilla-dev-s...@lists.mozilla.org
On 4/7/14, 5:42 PM, Kathleen Wilson wrote:
> 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
> websites and code signing trust bits for the RCA2 root cert. The request
> 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
>
Thank you to those of you who reviewed and contributed to this discussion.
> 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
>
I believe that the questions about this request that were raised during
this discussion have been addressed.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=926541
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages