info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GlobalSign Request to Include ECC Roots
178 views
Skip to first unread message
Kathleen Wilson
Jul 29, 2014, 6:26:08 PM7/29/14
to mozilla-dev-s...@lists.mozilla.org
GlobalSign has applied to include the �GlobalSign ECC Root CA - R4� and
�GlobalSign ECC Root CA - R5� root certificates, and turn on all three
trust bits and enable EV treatment for both roots.
GlobalSign, a privately owned organization, provides businesses and
individuals with SSL, SMIME and code signing certificates.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=825954
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=8441720
Noteworthy points:
* The primary documents, the CP/CPS, are in English.
https://www.globalsign.com/repository/
* CA Hierarchy: These root certs are offline and will sign internally
operated intermediate certificates.
* This request is to turn on all three trust bits for both root certs.
** CPS section 3.2.2: For SSL/TLS Certificates, the Applicant�s
ownership or control of all requested Domain Name(s) is authenticated by
one of the following methods:
� Using GlobalSign�s OneClickSSL protocol whereby the Applicant is
required to demonstrate control of a Domain Name by installing a
non-publicly trusted test Certificate of GlobalSign CA�s specification;
� By uploading specific metadata to a defined page on the domain;
� By direct confirmation with the contact listed by the Domain Name
Registrar in the WHOIS record;
� By successfully replying to a challenge response email sent to one or
more of the following email addresses:
o webm...@domain.com, postmaster@domain, ad...@domain.com,
admini...@domain.com, hostmaster@domain, or
o any email address listed as a contact field of the WHOIS record, or
o any address previously used for the successful validation of the
control of the domain subject to the re-verification requirements of
Section 3.3.1; or
� By receiving a reliable communication from the Domain Name Registrar
stating that the Registrant gives the Applicant permission to use the
Domain Name.
Further information may be requested from the Applicant and other
information and or methods may be utilized in order to demonstrate an
equivalent level of confidence.
** CPS section 3.2.2.1, Local Registration Authority Authentication: For
EPKI and MSSL accounts, GlobalSign CA sets authenticated organizational
details in the form of a Profile. Suitably authenticated account
administrators acting in the capacity of a Local Registration Authority
authenticate individuals affiliated with the organization and/or any
sub-domains owned or controlled by the organization. (Whilst LRA�s are
able to authenticate individuals under contract, all domains to be
authenticated will have previously been verified by GlobalSign CA).
** CPS section 3.2.2.3, Extended Validation Certificates (SSL and Code
Signing): For Extended Validation Certificates, the EV Guidelines are
followed.
** CPS section 3.2.3.1, Class 1 (Personal Sign 1 & PersonalSign 1 Demo
Certificates): The Applicant is required to demonstrate control of the
email address to which the Certificate relates.
** CPS section 3.2.3.2, Class 2 (PersonalSign2, SSL, Code Signing, PDF
Signing for Adobe CDS & AATL for Individuals): The Applicant is
required to demonstrate control of any email address to be included
within a Certificate. �
GlobalSign CA also authenticates the Applicant�s identity through one of
the following methods:
� Performing a telephone challenge/response to the Applicant using a
telephone number from a reliable source;
� Performing a postal challenge to the Applicant using an address
obtained from a reliable source;
� Receiving an attestation from an appropriate notary or trusted third
party that they have met the individual, and have inspected their
national photo ID document, and that the application details for the
order are correct; or
� The Applicant�s seal impression (in jurisdictions that permit their
use to legally sign a document) is included with any application
received in writing.
** CPS section 3.2.3.3, Class 3 (PersonalSign3 Pro Certificates): The
Applicant is required to demonstrate control of any email address to be
included within a Certificate. �
A face to face meeting is required to establish the individual�s
identity with an attestation from the notary or trusted third party that
they have met the individual and have inspected their national photo ID
document, and that the application details for the order are correct.
This is mandated within the business process for PersonalSign 3 Pro).
GlobalSign CA authenticates the Applicant�s authority to represent the
organization wishing to be named as the Subject in the Certificate by
one of the following methods:
� Performing a telephone challenge/response to the Applicant�s
organization using a telephone number from a reliable source; or
� Performing a postal challenge to the Applicant�s organization using an
address obtained from a reliable source.
** CPS section 3.2.5, Validation of Authority:
� PersonalSign1 Certificates - Verification that the Applicant has
control over the email address to be listed within the Certificate
through a challenge response mechanism.
� PersonalSign2 Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
included..
� NAESB Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
included (see Section 3.2.3.5.)
� PersonalSign3 Certificates - Verification through a reliable means of
communication with the organization that the Applicant represents the
organization. Personal appearance is mandatory before a suitable
Registration Authority to validate the personal credentials of the
Applicant together with verification that the Applicant has control over
the email address to be listed within the Certificate.
� Code Signing Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
that may be optionally listed within the Certificate.
� EV Code Signing Certificates - Verifying the authority of the contract
signer and Certificate approver in accordance with the EV Guidelines and
EV Code Signing Guidelines.
� DV/AlphaSSL Certificates - Validation of the ownership or control of
the domain name by a suitable challenge response mechanism. Either:-
-- Using GlobalSign�s OneClickSSL protocol whereby the Applicant is
required to demonstrate control of a domain by installing a non-publicly
trusted test Certificate of GlobalSign CA�s design,
-- By uploading specific metadata to a defined page on the domain,
-- By direct confirmation with the contact listed with the Domain Name
Registrar,
-- Successfully replying to a challenge response email sent to one or
more of the following email addresses: webm...@domain.com,
postmaster@domain, ad...@domain.com admini...@domain.com,
hostmaster@domain, or any address listed as a contact field of the WHOIS
record.
- If the Country code is included within the DN then GlobalSign
validates the Country based on the geo-location of the IP address
obtained by a DNS query.
� OV SSL Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has ownership or control of the
domain name by either a challenge response mechanism or direct
confirmation with the contact listed with the Domain Name Registrar or
WHOIS.
� EV SSL Certificates - Verifying the authority of the contract signer
and Certificate approver in accordance with the EV Guidelines.
� Time Stamping Certificates - Verification through a reliable means of
communication with the organization�s Applicant.
� CA for AATL Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
to be listed within the Certificate.
� PDF Signing for Adobe - Verification through a reliable means of
communication
CDS Certificates with the organization or individual Applicant.
� Trusted Root - Verification through a reliable means of communication
with the organization�s Applicant.
* EV Policy OID: 1.3.6.1.4.1.4146.1.1
** EV treatment is requested for both root certs.
* Root Cert URLs
https://secure.globalsign.net/cacert/Root-R4.crt
https://secure.globalsign.net/cacert/Root-R5.crt
* Test Websites
https://2038r4.globalsign.com/
https://2038r5.globalsign.com/
* CRL
http://crl.globalsign.com/gs/root-r4.crl
http://crl.globalsign.com/gs/root-r5.crl
* OCSP
http://ocsp2.globalsign.com/ecadminca1sha2g2
http://ocsp2.globalsign.com/ecadminca2sha2g2
* Audit: Annual audits are performed by Ernst & Young according to the
WebTrust criteria.
WebTrust for CA: https://cert.webtrust.org/ViewSeal?id=1690
WebTrust for EV: https://cert.webtrust.org/ViewSeal?id=1691
SSL Baseline Requirements: https://cert.webtrust.org/ViewSeal?id=1688
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** GlobalSign issues Wildcard DV certificates.
CPS section 3.1.1: Wildcard SSL Certificates include a wildcard asterisk
character. Before issuing a certificate with a wildcard character (*)
GlobalSign CA follows best practices to determine if the wildcard
character occurs in the first label position to the left of a
�registry-controlled� label or �public suffix�. (e.g. �*.com�,
�*.co.uk�, see RFC 6454 Section 8.2 for further explanation.) and if it
does, it will reject the request as the domain space must be owned or
controlled by the subscriber. e.g. *.globalsign.com
** GlobalSign provides pfx files to customers.
CPS section 6.1.2: GlobalSign CAs that create Private Keys on behalf of
Subscribers (AutoCSR) do so only when sufficient security is maintained
within the key generation process and any onward issuance process to the
Subscriber. For SSL/TLS Certificates, this is achieved through the use
of PCKS#12 (.pfx) files containing Private Keys and Certificates
encrypted by a sixteen (16) digit password. The first eight (8) digits
are system generated and provided to the Subscriber during the
enrollment process and the Subscriber decides the remaining eight (8).
For SMIME certificates, this is again achieved through the use of
PCKS#12 (.pfx) files containing Private Keys and Certificates encrypted
by an eight (8) digit Subscriber-selected password.
GlobalSign CA ensures the integrity of any Public/Private Keys and the
randomness of the key material through a suitable RNG or PRNG. If
GlobalSign CA detects or suspects that the Private Key has been
communicated to an unauthorized person or an organization not affiliated
with the Subscriber, then GlobalSign CA revokes all Certificates that
include the Public Key corresponding to the communicated Private Key.
GlobalSign CA does not archive Private Keys and ensures that any
temporary location where a Private Key may have existed in any memory
location during the generation process is purged.
** GlobalSign provides OV certificates which may include Internal IP
address and/or hostnames.
CPS section 3.2.4: For OV SSL/TLS Certificates only, GlobalSign CA
relies upon information provided by the Applicant to be included within
the subjectAlternativeName such as internal or non-public DNS names,
hostnames and RFC 1918 IP addresses. The Baseline Requirements define
the time frame for an industry wide deadline at which time these objects
may no longer be included within Certificates. Until such time these
items are classified as non-verified Subscriber information as ownership
cannot reasonably be validated.
This begins the discussion of the request from GlobalSign to include the
�GlobalSign ECC Root CA - R4� and �GlobalSign ECC Root CA - R5� root
certificates, and turn on all three trust bits and enable EV treatment
for both roots. 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
�GlobalSign ECC Root CA - R5� root certificates, and turn on all three
trust bits and enable EV treatment for both roots.
GlobalSign, a privately owned organization, provides businesses and
individuals with SSL, SMIME and code signing certificates.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=825954
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=8441720
Noteworthy points:
* The primary documents, the CP/CPS, are in English.
https://www.globalsign.com/repository/
* CA Hierarchy: These root certs are offline and will sign internally
operated intermediate certificates.
* This request is to turn on all three trust bits for both root certs.
** CPS section 3.2.2: For SSL/TLS Certificates, the Applicant�s
ownership or control of all requested Domain Name(s) is authenticated by
one of the following methods:
� Using GlobalSign�s OneClickSSL protocol whereby the Applicant is
required to demonstrate control of a Domain Name by installing a
non-publicly trusted test Certificate of GlobalSign CA�s specification;
� By uploading specific metadata to a defined page on the domain;
� By direct confirmation with the contact listed by the Domain Name
Registrar in the WHOIS record;
� By successfully replying to a challenge response email sent to one or
more of the following email addresses:
o webm...@domain.com, postmaster@domain, ad...@domain.com,
admini...@domain.com, hostmaster@domain, or
o any email address listed as a contact field of the WHOIS record, or
o any address previously used for the successful validation of the
control of the domain subject to the re-verification requirements of
Section 3.3.1; or
� By receiving a reliable communication from the Domain Name Registrar
stating that the Registrant gives the Applicant permission to use the
Domain Name.
Further information may be requested from the Applicant and other
information and or methods may be utilized in order to demonstrate an
equivalent level of confidence.
** CPS section 3.2.2.1, Local Registration Authority Authentication: For
EPKI and MSSL accounts, GlobalSign CA sets authenticated organizational
details in the form of a Profile. Suitably authenticated account
administrators acting in the capacity of a Local Registration Authority
authenticate individuals affiliated with the organization and/or any
sub-domains owned or controlled by the organization. (Whilst LRA�s are
able to authenticate individuals under contract, all domains to be
authenticated will have previously been verified by GlobalSign CA).
** CPS section 3.2.2.3, Extended Validation Certificates (SSL and Code
Signing): For Extended Validation Certificates, the EV Guidelines are
followed.
** CPS section 3.2.3.1, Class 1 (Personal Sign 1 & PersonalSign 1 Demo
Certificates): The Applicant is required to demonstrate control of the
email address to which the Certificate relates.
** CPS section 3.2.3.2, Class 2 (PersonalSign2, SSL, Code Signing, PDF
Signing for Adobe CDS & AATL for Individuals): The Applicant is
required to demonstrate control of any email address to be included
within a Certificate. �
GlobalSign CA also authenticates the Applicant�s identity through one of
the following methods:
� Performing a telephone challenge/response to the Applicant using a
telephone number from a reliable source;
� Performing a postal challenge to the Applicant using an address
obtained from a reliable source;
� Receiving an attestation from an appropriate notary or trusted third
party that they have met the individual, and have inspected their
national photo ID document, and that the application details for the
order are correct; or
� The Applicant�s seal impression (in jurisdictions that permit their
use to legally sign a document) is included with any application
received in writing.
** CPS section 3.2.3.3, Class 3 (PersonalSign3 Pro Certificates): The
Applicant is required to demonstrate control of any email address to be
included within a Certificate. �
A face to face meeting is required to establish the individual�s
identity with an attestation from the notary or trusted third party that
they have met the individual and have inspected their national photo ID
document, and that the application details for the order are correct.
This is mandated within the business process for PersonalSign 3 Pro).
GlobalSign CA authenticates the Applicant�s authority to represent the
organization wishing to be named as the Subject in the Certificate by
one of the following methods:
� Performing a telephone challenge/response to the Applicant�s
organization using a telephone number from a reliable source; or
� Performing a postal challenge to the Applicant�s organization using an
address obtained from a reliable source.
** CPS section 3.2.5, Validation of Authority:
� PersonalSign1 Certificates - Verification that the Applicant has
control over the email address to be listed within the Certificate
through a challenge response mechanism.
� PersonalSign2 Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
included..
� NAESB Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
included (see Section 3.2.3.5.)
� PersonalSign3 Certificates - Verification through a reliable means of
communication with the organization that the Applicant represents the
organization. Personal appearance is mandatory before a suitable
Registration Authority to validate the personal credentials of the
Applicant together with verification that the Applicant has control over
the email address to be listed within the Certificate.
� Code Signing Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
that may be optionally listed within the Certificate.
� EV Code Signing Certificates - Verifying the authority of the contract
signer and Certificate approver in accordance with the EV Guidelines and
EV Code Signing Guidelines.
� DV/AlphaSSL Certificates - Validation of the ownership or control of
the domain name by a suitable challenge response mechanism. Either:-
-- Using GlobalSign�s OneClickSSL protocol whereby the Applicant is
required to demonstrate control of a domain by installing a non-publicly
trusted test Certificate of GlobalSign CA�s design,
-- By uploading specific metadata to a defined page on the domain,
-- By direct confirmation with the contact listed with the Domain Name
Registrar,
-- Successfully replying to a challenge response email sent to one or
more of the following email addresses: webm...@domain.com,
postmaster@domain, ad...@domain.com admini...@domain.com,
hostmaster@domain, or any address listed as a contact field of the WHOIS
record.
- If the Country code is included within the DN then GlobalSign
validates the Country based on the geo-location of the IP address
obtained by a DNS query.
� OV SSL Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has ownership or control of the
domain name by either a challenge response mechanism or direct
confirmation with the contact listed with the Domain Name Registrar or
WHOIS.
� EV SSL Certificates - Verifying the authority of the contract signer
and Certificate approver in accordance with the EV Guidelines.
� Time Stamping Certificates - Verification through a reliable means of
communication with the organization�s Applicant.
� CA for AATL Certificates - Verification through a reliable means of
communication with the organization or individual Applicant together
with verification that the Applicant has control over any email address
to be listed within the Certificate.
� PDF Signing for Adobe - Verification through a reliable means of
communication
CDS Certificates with the organization or individual Applicant.
� Trusted Root - Verification through a reliable means of communication
with the organization�s Applicant.
* EV Policy OID: 1.3.6.1.4.1.4146.1.1
** EV treatment is requested for both root certs.
* Root Cert URLs
https://secure.globalsign.net/cacert/Root-R4.crt
https://secure.globalsign.net/cacert/Root-R5.crt
* Test Websites
https://2038r4.globalsign.com/
https://2038r5.globalsign.com/
* CRL
http://crl.globalsign.com/gs/root-r4.crl
http://crl.globalsign.com/gs/root-r5.crl
* OCSP
http://ocsp2.globalsign.com/ecadminca1sha2g2
http://ocsp2.globalsign.com/ecadminca2sha2g2
* Audit: Annual audits are performed by Ernst & Young according to the
WebTrust criteria.
WebTrust for CA: https://cert.webtrust.org/ViewSeal?id=1690
WebTrust for EV: https://cert.webtrust.org/ViewSeal?id=1691
SSL Baseline Requirements: https://cert.webtrust.org/ViewSeal?id=1688
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** GlobalSign issues Wildcard DV certificates.
CPS section 3.1.1: Wildcard SSL Certificates include a wildcard asterisk
character. Before issuing a certificate with a wildcard character (*)
GlobalSign CA follows best practices to determine if the wildcard
character occurs in the first label position to the left of a
�registry-controlled� label or �public suffix�. (e.g. �*.com�,
�*.co.uk�, see RFC 6454 Section 8.2 for further explanation.) and if it
does, it will reject the request as the domain space must be owned or
controlled by the subscriber. e.g. *.globalsign.com
** GlobalSign provides pfx files to customers.
CPS section 6.1.2: GlobalSign CAs that create Private Keys on behalf of
Subscribers (AutoCSR) do so only when sufficient security is maintained
within the key generation process and any onward issuance process to the
Subscriber. For SSL/TLS Certificates, this is achieved through the use
of PCKS#12 (.pfx) files containing Private Keys and Certificates
encrypted by a sixteen (16) digit password. The first eight (8) digits
are system generated and provided to the Subscriber during the
enrollment process and the Subscriber decides the remaining eight (8).
For SMIME certificates, this is again achieved through the use of
PCKS#12 (.pfx) files containing Private Keys and Certificates encrypted
by an eight (8) digit Subscriber-selected password.
GlobalSign CA ensures the integrity of any Public/Private Keys and the
randomness of the key material through a suitable RNG or PRNG. If
GlobalSign CA detects or suspects that the Private Key has been
communicated to an unauthorized person or an organization not affiliated
with the Subscriber, then GlobalSign CA revokes all Certificates that
include the Public Key corresponding to the communicated Private Key.
GlobalSign CA does not archive Private Keys and ensures that any
temporary location where a Private Key may have existed in any memory
location during the generation process is purged.
** GlobalSign provides OV certificates which may include Internal IP
address and/or hostnames.
CPS section 3.2.4: For OV SSL/TLS Certificates only, GlobalSign CA
relies upon information provided by the Applicant to be included within
the subjectAlternativeName such as internal or non-public DNS names,
hostnames and RFC 1918 IP addresses. The Baseline Requirements define
the time frame for an industry wide deadline at which time these objects
may no longer be included within Certificates. Until such time these
items are classified as non-verified Subscriber information as ownership
cannot reasonably be validated.
This begins the discussion of the request from GlobalSign to include the
�GlobalSign ECC Root CA - R4� and �GlobalSign ECC Root CA - R5� root
certificates, and turn on all three trust bits and enable EV treatment
for both roots. 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
Matt Palmer
Jul 29, 2014, 8:39:00 PM7/29/14
to dev-secur...@lists.mozilla.org
OK, let's dive into the CPS dissection game...
On Tue, Jul 29, 2014 at 03:26:08PM -0700, Kathleen Wilson wrote:
> ** CPS section 3.2.2.3, Extended Validation Certificates (SSL and
> Code Signing): For Extended Validation Certificates, the EV
> Guidelines are followed.
I'm new to this, so perhaps the answer is "yes, of course it is", but is
that a sufficient description of how EV certs are validated? The EV
guidelines contain wording such as "Acceptable methods [...] include", which
suggests to me that other methods *could* be used. What are the methods
that are used by this CA for issuance of certificates under this root?
At the very least, I think there needs to be better description of *which*
EV guidelines are being followed. "Guidelines for the Issuance and
Management of Extended Validation Certificates, version 1.4.9 or later, as
published by the CA/Browser Forum" would be a far less ambiguous
description.
> ** CPS section 3.2.3.1, Class 1 (Personal Sign 1 & PersonalSign 1
> Demo Certificates): The Applicant is required to demonstrate control
> of the email address to which the Certificate relates.
How is this done?
- Matt
On Tue, Jul 29, 2014 at 03:26:08PM -0700, Kathleen Wilson wrote:
> ** CPS section 3.2.2.3, Extended Validation Certificates (SSL and
> Code Signing): For Extended Validation Certificates, the EV
> Guidelines are followed.
that a sufficient description of how EV certs are validated? The EV
guidelines contain wording such as "Acceptable methods [...] include", which
suggests to me that other methods *could* be used. What are the methods
that are used by this CA for issuance of certificates under this root?
At the very least, I think there needs to be better description of *which*
EV guidelines are being followed. "Guidelines for the Issuance and
Management of Extended Validation Certificates, version 1.4.9 or later, as
published by the CA/Browser Forum" would be a far less ambiguous
description.
> ** CPS section 3.2.3.1, Class 1 (Personal Sign 1 & PersonalSign 1
> Demo Certificates): The Applicant is required to demonstrate control
> of the email address to which the Certificate relates.
- Matt
Jeremy Rowley
Jul 30, 2014, 5:01:04 PM7/30/14
to Matt Palmer, dev-secur...@lists.mozilla.org
I do not think specifying a version number is required. All CAs issuing EV certs (or SSL) are required to abide by the latest version of the guidelines and attest to that fact in their CPS using the prescribed CAB Forum language:
"[Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document."
Therefore, it's always the latest version, as adopted.
Jeremy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
"[Name of CA] conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document."
Therefore, it's always the latest version, as adopted.
Jeremy
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Kathleen Wilson
Aug 12, 2014, 8:00:57 PM8/12/14
to mozilla-dev-s...@lists.mozilla.org
Actually, I think Matt's question was not about which version of the EV
Guidelines was followed, but rather about which of the allowed methods
of verification are used.
GobalSign's CPS section 3.2.2.3 just says: "For Extended Validation
*does* to authenticate the organization identity for EV certs.
CPS section 3.2.2 tells us about what GlobalSign does for all
certificates *other than EV certs*...
CPS section 3.2.2: "For all Certificates that include an organization
identity, Applicants are required to indicate the organization�s name
and registered or trading address. For all Certificates *other than
Extended Validation*, the legal existence, legal name, legal form and
requested address of the organization is verified using one of the
following:"
So, I think Matt has a valid point -- Saying that the EV Guidelines are
followed doesn't really tell us *how* GlobalSign verifies that the EV
certificate subscriber owns/controls the domain name, has the authority
to request the certificate on behalf of the organization, and the
organization identity.
Kathleen
Guidelines was followed, but rather about which of the allowed methods
of verification are used.
GobalSign's CPS section 3.2.2.3 just says: "For Extended Validation
Certificates, the EV Guidelines are followed."
So, that section doesn't tell us anything about what GlobalSign actually
*does* to authenticate the organization identity for EV certs.
CPS section 3.2.2 tells us about what GlobalSign does for all
certificates *other than EV certs*...
CPS section 3.2.2: "For all Certificates that include an organization
identity, Applicants are required to indicate the organization�s name
and registered or trading address. For all Certificates *other than
Extended Validation*, the legal existence, legal name, legal form and
requested address of the organization is verified using one of the
following:"
So, I think Matt has a valid point -- Saying that the EV Guidelines are
followed doesn't really tell us *how* GlobalSign verifies that the EV
certificate subscriber owns/controls the domain name, has the authority
to request the certificate on behalf of the organization, and the
organization identity.
Kathleen
Kathleen Wilson
Aug 13, 2014, 12:57:22 PM8/13/14
to mozilla-dev-s...@lists.mozilla.org
On 8/12/14, 10:58 PM, Steve Roylance wrote:
> Hi Kathleen,
>
> I see the underlying question that you (and Matt) wanted us to answer.
> Apologies in not being complete in my response the first time around.
>
> The reason we are specific in the CPS with regards to Organizational vetting
> (for everything other than EV) is a historical one. Prior to the Baseline
> Requirements we had to stipulate exactly how we validated a company as there
> were no external standards to point towards. Of course this has now
> changed in that like EV we 'could' also reference the external methods
> allowed by the Baseline Requirements, however, as we still have a number of
> other certificate types that incorporate Organization information we
> specifically reference the methods we use for these. In the short term we
> don't plan on changing the wording as we'll soon have guidelines for BR
> based Code Signing too.
>
> In response to this discussion thread I'm going to suggest to our Policy
> Authority 2 (in charge of CP/CPS) that when BR Code Signing is released, we
> reword the sections, referring out to EV and BR guidelines and only
> highlight if there are differences for the remaining products.
>
> As far as what we actually do for Extended Validation then we follow the
> guidelines and therefore also the allowed alternatives and our auditors
> verify this on a yearly basis. If we were to incorporate actual processes
> then we would have to sync updates to the CPS with changes to EV (Rather
> than our internal process documents) and that makes things harder all round.
>
> Does that answer your concern?
>
> Note that I'm in our Singapore office today and flying back tomorrow so
> additional responses will be delayed until Friday UK time if I didn't
> address your concern.
>
> Kind Regards
>
> Steve
>
The reason I didn't notice this before, is because I didn't notice the
part in CPS section 3.2.2 that said "For all Certificates other than
Extended Validation"
I do *not* believe that simply referencing the BRs and the EV Guidelines
is sufficient.
For example, lets look at domain verification for SSL certs.
Baseline Requirements section 11.1.1 lists several ways in which the CA
may confirm that the certificate subscriber owns/controls the domain
name to be included in the certificate. Simply referencing section 11 of
the BRs does not tell us which of those options the CA uses.
Also, I don't believe that the following has changed, and I don't
believe that referencing BR section 11 provides sufficient information
to satisfy this.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
"The CA's public documentation needs to provide sufficient information
describing the steps taken by the CA to confirm that the certificate
subscriber owns/controls the domain name to be included in the
certificate. For instance, if a challenge-response type of procedure is
used, then there needs to be a brief description of the process. If
public resources are used, then there should be a description of which
public resources are used, what data is retrieved from public resources,
and how that data is used to verify that the certificate subscriber
owns/controls the domain name."
Kathleen
> Hi Kathleen,
>
> I see the underlying question that you (and Matt) wanted us to answer.
> Apologies in not being complete in my response the first time around.
>
> The reason we are specific in the CPS with regards to Organizational vetting
> (for everything other than EV) is a historical one. Prior to the Baseline
> Requirements we had to stipulate exactly how we validated a company as there
> were no external standards to point towards. Of course this has now
> changed in that like EV we 'could' also reference the external methods
> allowed by the Baseline Requirements, however, as we still have a number of
> other certificate types that incorporate Organization information we
> specifically reference the methods we use for these. In the short term we
> don't plan on changing the wording as we'll soon have guidelines for BR
> based Code Signing too.
>
> In response to this discussion thread I'm going to suggest to our Policy
> Authority 2 (in charge of CP/CPS) that when BR Code Signing is released, we
> reword the sections, referring out to EV and BR guidelines and only
> highlight if there are differences for the remaining products.
>
> As far as what we actually do for Extended Validation then we follow the
> guidelines and therefore also the allowed alternatives and our auditors
> verify this on a yearly basis. If we were to incorporate actual processes
> then we would have to sync updates to the CPS with changes to EV (Rather
> than our internal process documents) and that makes things harder all round.
>
> Does that answer your concern?
>
> Note that I'm in our Singapore office today and flying back tomorrow so
> additional responses will be delayed until Friday UK time if I didn't
> address your concern.
>
> Kind Regards
>
> Steve
>
The reason I didn't notice this before, is because I didn't notice the
part in CPS section 3.2.2 that said "For all Certificates other than
Extended Validation"
I do *not* believe that simply referencing the BRs and the EV Guidelines
is sufficient.
For example, lets look at domain verification for SSL certs.
Baseline Requirements section 11.1.1 lists several ways in which the CA
may confirm that the certificate subscriber owns/controls the domain
name to be included in the certificate. Simply referencing section 11 of
the BRs does not tell us which of those options the CA uses.
Also, I don't believe that the following has changed, and I don't
believe that referencing BR section 11 provides sufficient information
to satisfy this.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
"The CA's public documentation needs to provide sufficient information
describing the steps taken by the CA to confirm that the certificate
subscriber owns/controls the domain name to be included in the
certificate. For instance, if a challenge-response type of procedure is
used, then there needs to be a brief description of the process. If
public resources are used, then there should be a description of which
public resources are used, what data is retrieved from public resources,
and how that data is used to verify that the certificate subscriber
owns/controls the domain name."
Kathleen
Kathleen Wilson
Aug 13, 2014, 2:57:18 PM8/13/14
to mozilla-dev-s...@lists.mozilla.org
On 8/13/14, 11:43 AM, Medin, Steven wrote:
> The BR on which the EVG rely do state that our
> CPS must say what we do in detail.
Good point.
BR section 8.2.1: "The CA SHALL develop, implement, enforce, and
annually update a Certificate Policy and/or Certification Practice
Statement that describes in detail how the CA implements the latest
version of these Requirements."
> I suggest that "all of the above" is a
> viable response to that due to the gamut of situations we face globally.
When I review a CP/CPS, I'm looking for information that demonstrates
compliance with Mozilla's policy. Among other things, I look for a
description of the actions that a CA takes to confirm ownership/control
of the domain name to be included in the certificate.
The EV Guidelines take subscriber verification to a higher level, so I
am fine with a CP/CPS that says that *in addition* to the steps taken
for DV/OV certs, the EV Guidelines are followed.
Kathleen
> The BR on which the EVG rely do state that our
> CPS must say what we do in detail.
Good point.
BR section 8.2.1: "The CA SHALL develop, implement, enforce, and
annually update a Certificate Policy and/or Certification Practice
Statement that describes in detail how the CA implements the latest
version of these Requirements."
> I suggest that "all of the above" is a
> viable response to that due to the gamut of situations we face globally.
When I review a CP/CPS, I'm looking for information that demonstrates
compliance with Mozilla's policy. Among other things, I look for a
description of the actions that a CA takes to confirm ownership/control
of the domain name to be included in the certificate.
The EV Guidelines take subscriber verification to a higher level, so I
am fine with a CP/CPS that says that *in addition* to the steps taken
for DV/OV certs, the EV Guidelines are followed.
Kathleen
Kathleen Wilson
Aug 14, 2014, 1:00:31 PM8/14/14
to mozilla-dev-s...@lists.mozilla.org
I added a paragraph about this to the Recommended Practices wiki page...
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
==
It is not sufficient to simply reference section 11 of the CA/Brower
Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in
uses, and is insufficient for describing how the CA conforms to the BRs.
BR #8.2.1 says: "The CA SHALL develop, implement, enforce, and annually
Kathleen
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
==
It is not sufficient to simply reference section 11 of the CA/Brower
Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in
which the CA may confirm that the certificate subscriber owns/controls
the domain name to be included in the certificate. Simply referencing
section 11 of the BRs does not specify which of those options the CA
the domain name to be included in the certificate. Simply referencing
uses, and is insufficient for describing how the CA conforms to the BRs.
BR #8.2.1 says: "The CA SHALL develop, implement, enforce, and annually
update a Certificate Policy and/or Certification Practice Statement that
describes in detail how the CA implements the latest version of these
Requirements."
==
describes in detail how the CA implements the latest version of these
Requirements."
Kathleen
Kathleen Wilson
Aug 21, 2014, 6:25:17 PM8/21/14
to mozilla-dev-s...@lists.mozilla.org
On 7/29/14, 3:26 PM, Kathleen Wilson wrote:
> GlobalSign has applied to include the �GlobalSign ECC Root CA - R4� and
> �GlobalSign ECC Root CA - R5� root certificates, and turn on all three
> trust bits and enable EV treatment for both roots.
>
Thanks to those of you who have already contributed to this discussion.
> GlobalSign has applied to include the �GlobalSign ECC Root CA - R4� and
> �GlobalSign ECC Root CA - R5� root certificates, and turn on all three
> trust bits and enable EV treatment for both roots.
>
While we wait for GlobalSign to update their CPS...
Does anyone else have comments/questions/concerns about this request?
Kathleen
Kathleen Wilson
Sep 9, 2014, 6:43:01 PM9/9/14
to mozilla-dev-s...@lists.mozilla.org
GlobalSign confirms that the certificate subscriber owns/controls the
domain to be included in EV certificates.
> CPS section 3.2.2: "For all Certificates *other than
> Extended Validation*, the legal existence, legal name, legal form and
> requested address of the organization is verified using one of the
> following:"
So GlobalSign has updated their CP/CPS as described here:
> requested address of the organization is verified using one of the
> following:"
https://bugzilla.mozilla.org/show_bug.cgi?id=825954#c13
While we are waiting for the updated CP/CPS to be posted on GlobalSign's
website...
Does anyone have any further comments or questions about this root
inclusion request?
If not, then after confirming that the updated CP/CPS are posted on
their website, I will close this discussion and recommend approval of
this inclusion request in the bug.
Thanks,
Kathleen
Kathleen Wilson
Sep 12, 2014, 6:21:34 PM9/12/14
to mozilla-dev-s...@lists.mozilla.org
discussion about the request from GlobalSign to include the �GlobalSign
ECC Root CA - R4� and �GlobalSign ECC Root CA - R5� root certificates,
and turn on all three trust bits and enable EV treatment for both roots.
GlobalSign's website ( https://www.globalsign.com/repository/ ) has been
and turn on all three trust bits and enable EV treatment for both roots.
updated with their new CP and CPS, and I confirm that CPS sections 3.2.2
and 3.2.7 have been updated to address the concern that was raised in
this discussion.
In particular,
https://www.globalsign.com/repository/GlobalSign_CA_CPS_v7.8.pdf
has the changes listed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=825954#c14
There are no further action items resulting from this discussion, and
the questions that were raised have been resolved.
I am closing this discussion, and I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=825954
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages