Kathleen, out of curiosity -- what's the difference between a "Root Renewal Request" and a simple request to add a new root to the Mozilla root store? Are they essentially the same process, or is a root renewal request treated differently?
On Thursday, October 30, 2014 11:17:41 AM UTC-7, Kathleen Wilson wrote: > 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
