IdenTrust has applied to include the “IdenTrust Commercial Root CA 1”
and “IdenTrust Public Sector Root CA 1” root certificates, and turn on
the Websites and Email trust bits for both. The “IdenTrust Commercial
Root CA 1” root will eventually replace the “DST Root X3” certificate,
and the “IdenTrust Public Sector Root CA 1” root will eventually replace
the “DST ACES X6” certificate. Both of the currently-included root
certificates were included via Bugzilla Bug #394733.
IdenTrust is a for-profit corporation serving the private, commercial,
and government sectors.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590
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=8504852
Noteworthy points:
* The primary documents are in English
Documentation for the “IdenTrust Commercial Root CA 1” root:
TrustID Document Repository:
https://secure.identrust.com/certificates/policy/ts/
TrustID CPS:
https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.3_20140109.pdf
TrustID CP:
https://secure.identrust.com/certificates/policy/ts/TrustID_CP_v1.6.1_20130912.pdf
Documentation for the “IdenTrust Public Sector Root CA 1” root:
ACES Document Repository:
https://secure.identrust.com/certificates/policy/aces/
ACES CPS:
https://secure.identrust.com/certificates/policy/aces/dst-aces-cps-v20040617.pdf
ACES CPS Addendum:
https://secure.identrust.com/certificates/policy/aces/IdenTrust-Addendum-2013-11-26.pdf
* CA Hierarchy:
** “IdenTrust Commercial Root CA 1” root:
The intent is to generate the subordinate CA Certificates that will
support the current lines of business under the root being replaced. At
this time not all of the subordinate CA certificates have been generated
(names may change)
- [Internal]TrustID CA A52 (s/mime certificates)
- [Internal]TrustID CA A12 (Device/SSL Certificates)
In the future, there is the possibility of issuance of externally
operated CAs under this root. In such case, IdenTrust will favor the
independently audited and publicly disclose subordinate CA model of
operation.
Note that the “DST Root X3” root has signed one subordinate CA that is
externally operated. This subordinate CA has a policy publicly
published and has been audited under the WebTrust regime.
** “IdenTrust Public Sector Root CA 1” root:
The intent is to generate the following subordinate under this root:
- [Internal]IdenTrust ACES CA 2 (s/mime, device/SSL certificates)
There are no plans to have externally operated subordinate CAs off this
root at this time
Note that there are no externally-operated subordinate CAs that have
been signed by the “DST ACES X6” root.
* This request is to turn on the Websites and Email trust bits for both
root certs. EV treatment is not requested.
** “IdenTrust Commercial Root CA 1” root:
*** TrustID CPS section 3.2.7.1: To ensure that requests for TrustID SSL
Certificates are properly verified, IdenTrust and RAs conduct two
additional checks when necessary:
(1) IdenTrust and RAs maintain internal lists of prior denied
applications identified as posing a risk; and
(2) IdenTrust and RAs will check high risk domain requests against an
authoritative third party list prior to issuance.
Information returned from such checks is used during the application
process by an LRA within IdenTrust or an RA when identifying potentially
illegitimate Certificate requests. If an RA is elected to perform
verification processes, IdenTrust will verify that the RA’s processes
used to identify high risk domain requests and prior denied requests
provide a level of assurance that is equal to or exceeds the same level
of assurance provided by the process described below.
*** TrustID CPS section 3.2.7.2: IdenTrust verifies that the PKI Sponsor
has the right to use or has control of the FQDN(s) or IP address(es)
listed in the Certificate application by following the steps listed below.
The LRA confirms the Domain registrant’s rights by doing the following:
1) The Domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
2) Once the Domain Name registrant is identified from a database record
he or she is contacted via email. In this email the Domain Name
registrant will be asked:
a. to confirm or deny the right of the PKI Sponsor to be issued a Device
Certificate for the Domain Name(s) for which the PKI Sponsor has applied;
b. if they would like to provide the names other potential PKI
Sponsor(s) that may request the same type of Certificate; and
c. with respect only to applications for Wildcard Certificates, to
confirm or deny control over the entire Domain Namespace of the FQDN
provided and that such control is rightful.
If the PKI Sponsor applies for a Domain Name that contains a two-letter
country code (ccTLD) (e.g. www.identrust.uk as opposed to
www.identrust.com), this confirmation will be sought from the Domain
Name level to which the ccTLD applies. This means that the LRA cannot
obtain verification from www.identrust.com if the PKI Sponsor is
applying for a Domain Name from www.identrust.uk.
*** Trust ID CPS section 3.2.5:
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the personal email address provided in the application.
Within that automated email message there is a link that guides the
Applicant/PKI Sponsor to a server-authenticated SSL/TLS secured web site
and instructions to provide out-of-band information, including an
Account Password. This Account Password was created during the
application by the Applicant/PKI Sponsor and it is secure only to the
Applicant/PKI Sponsor. When the Applicant/PKI Sponsor provides and
submits the Account Password created during the application accurately
the verification of the email address is completed and the verification
status is automatically updated within the Applicant/PKI Sponsor’s
application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
** “IdenTrust Public Sector Root CA 1” root:
*** ACES CPS Addendum section 3.1.9.4:
Verification of Authorization by Domain Name Registrant
IdenTrust verifies that the PKI Sponsor has the right to issue or has
control of the Fully-Qualified Domain Name(s) from the SAN extension and
public IP address(es) listed in the Certificate application by following
the steps listed below.
The LRA confirms the rights by the Domain Registrant by doing the following:
(1)The domain(s) supplied by the PKI Sponsor is placed into a search
engine (e.g. WHOIS) and the LRA records the contact information for the
Domain Name Registrant.
(2) Once the Domain Name Registrant is identified from a database record
he or she are contacted via email to confirm the information provided by
the PKI Sponsor to confirm or deny the right of the PKI Sponsor to be
issued the certificate for the Domain Name(s) for which the PKI Sponsor
has applied. It is through this process that IdenTrust ensures that SSL
Certificates are issued with the consent of the owner of each FQDN
contained within the Certificate.During this exchange the Domain Name
Registrant will have the opportunity to name other potential PKI Sponsor(s).
If the PKI Sponsor applies for a domain that is a two-letter country
code (ccTLD), this confirmation will be sought from the Domain Name
level to which the ccTLD applies.
*** ACES Addendum section 3.1.9.7
Email verification when required can be done in two ways; electronically
and manually through a list submitted by a Trusted Agent. If the
application for a Certificate requires email verification the
application cannot be approved until the specified steps for electronic
or manual of verification is complete.
- Electronic Verification of Email: When an Applicant/PKI Sponsor
submits an application through a secure online form, an automated email
is sent to the Applicant/PKI Sponsor’s email address provided in the
application. Within that automated email message there is a link that
guides the Applicant/PKI Sponsor to a server-authenticated SSL/TLS
secured web site and instructions to provide out-of-band information,
including in Account passphrase Password. This Account Password was
created during the application by the Applicant/PKI Sponsor and it is
secure only to the Applicant/PKI Sponsor. When the Applicant/PKI Sponsor
provides and submits the passphrase Account Password created during the
application accurately the verification of the email address is
completed and the verification status is automatically updated within
the Applicant/PKI Sponsor’s application record.
- Manual Verification of Email: When a Trusted Agent provides the list
of authorized Applicants/PKI Sponsors, the email address is validated by
the Trusted Agent based on the internal knowledge of the Sponsoring
Organization. The Trusted Agent may use internal databases and
directories to ensure the email accuracy.
* EV Policy OID: Not requesting EV treatment
* Root Cert URLs
https://bugzilla.mozilla.org/attachment.cgi?id=8473319
http://validation.identrust.com/roots/commercialrootca1.p7c
https://bugzilla.mozilla.org/attachment.cgi?id=8473320
http://validation.identrust.com/roots/publicrootca1.p7c
* Test Websites
https://sha2ssl-trustidvalid.identrustssl.com/
https://sha2ssl-acesvalid.identrust.com/
Comprehensive list: http://testssl.identrust.com/
* CRL
http://validation.identrust.com/crl/commercialrootca1.crl
http://validation.identrust.com/crl/trustidcaa52.crl
http://validation.identrust.com/crl/publicrootca1.crl
http://validation.identrust.com/crl/acesca2.crl
* OCSP
http://commercial.ocsp.identrust.com
http://public.ocsp.identrust.com
* Audit: Annual audits are performed by BrightLine according to the
WebTrust CA and WebTrust Baseline Requirements audit criteria.
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://cert.webtrust.org/SealFile?seal=1720&file=pdf
https://secure.identrust.com/certificates/policy/ts/current-baseline-requirements-audit.pdf
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties
IdenTrust validates Domains for SSL certificates issued and does not
delegate such validation. See TrustID CPS section 3.2.7.2 and ACES CPS
Addendum 3.1.9.4.
IdenTrust allows Trusted Agents to, in particular cases, manually
validate the email of certificates. Trusted Agents are employees of the
organizations requesting the certificate and are under agreement with
IdenTrust. Trusted Agents validation is limited to emails within their
organization and only in circumstances where automatic validation is not
possible. See TrustID CPS section 3.2.5 and ACES CPS Addendum section
3.1.9.7 for detail.
This begins the discussion of the request from IdenTrust to include the
“IdenTrust Commercial Root CA 1” and “IdenTrust Public Sector Root CA 1”
root certificates, and turn on the Websites and Email trust bits for
both. 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
