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 [email protected], postmaster@domain, [email protected],
[email protected], 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: [email protected],
postmaster@domain, [email protected] [email protected],
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
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
