This request by ISRG is to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit.
Internet Security Research Group (ISRG) offers server authentication certificates to the general public around the world.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1204656
And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8727954
Noteworthy points:
* The primary documents are the CP and CPS, which are provided in English.
Document Repository:
https://letsencrypt.org/repository/
CP:
https://letsencrypt.org/documents/ISRG-CP-September-9-2015.pdf
CPS:
https://letsencrypt.org/documents/ISRG-CPS-March-16-2016.pdf
* CA Hierarchy: This root signs internally-operated intermediate certificates which sign DV SSL certificates. In the future, there may be externally-operated subCAs, but the CP/CPS requires that they be audited annually according to the CA/Browser Forum Baseline Requirements.
Cross-signing with "DST Root CA X3" root that is owned by IdenTrust and included in NSS.
CA Hierarchy Diagram:
https://bugzilla.mozilla.org/attachment.cgi?id=8660928
* This request is to enable the Websites trust bit.
** CP section
3.2.2.2: For each Name listed in a DV-SSL Certificate, the CA shall confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this Section) 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" in the local part, followed by the at-sign ("@"), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
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; or
7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.
Note: For purposes of determining the appropriate domain name level or Domain Namespace, the registerable Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain (ccTLD), then the domain level is whatever is allowed for registration according to the rules of that ccTLD.
If the CA relies upon a Domain Authorization Document to confirm the Applicant's control over a FQDN, then the Domain Authorization Document must substantiate that the communication came from either the Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain Name Registrar listed in the WHOIS. The CA must verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued certificate and that the Domain Name's WHOIS record has not been modified since the previous certificate's issuance.
** CPS section
3.2.2.2: For DV-SSL Certificates, the CA provides a secure means of validating the Applicant's control over, the device and domain name for which a Certificate is requested. The means of validating such ownership is consistent with the relevant CA/B Forum Baseline Requirements.
When an Applicant applies for a DV-SSL Certificate, identification will be performed on the basis of demonstrating control of the Domain Name requested. There are several different challenges that the ACME client may be asked to respond to during the process, e.g. the server might challenge the device or Applicant to provision a record in the DNS under that Domain Name requested to be part of the Certificate or to provision a file on a web server referenced by an A record under that Domain Name. When the Applicant prompts the machine to submit this information, a response from the server will indicate whether what the Applicant provided was successfully verified as proof of control over the authenticated Domain Name or not. By providing the correct information to the response that is requested, the Applicant has demonstrated control over the authenticated Domain Name and can proceed to Issuance, retrieval, and installation of that DV-SSL Certificate.
** CPS section 4.2.2: The CA approves an Applicant's Certificate application or request from the ACME client for a DV-SSL Certificate if the I&A processes described in Section 3.2 and 3.3 are completed successfully.
Certificate applications will be approved or rejected within 30 days of application receipt by the CA, or such other period that is compliant with the CA/B Forum Baseline Requirements.
The CA terminates an Applicant registration process if:
- The Applicant's identity (for Administrative Certificate) or demonstrated control of the domain as per the challenge presented to the ACME client, by the CA server (for DV-SSL Certificates) cannot be established in accordance with identity proofing requirements;
- Not all forms necessary to establish I&A for Administrative Certificates are submitted on a timely basis;
- For DV-SSL Certificates, the Applicant is unable to establish or provide verifiable evidence to that they are authorized to request the Certificate for the FQDN from the Domain Administrator in a form prescribed by the CA/B Forum; and/or
- The CA is unable to verify or process the Applicant's payment information (where payment information is required).
* EV Policy OID: Not requesting EV treatment
* Root Certificate:
https://letsencrypt.org/certs/isrgrootx1.der
* Test Website:
https://helloworld.letsencrypt.org/
* CRL URLs:
CRL HTTP URL:
http://crl.root-x1.letsencrypt.org/
CRL issuing frequency for subordinate end-entity certificates: We will not issue CRLs for end-entity certificates.
CRL issuing frequency for subordinate CA certificates: At least once every six months.
* OCSP URL(s)
http://ocsp.root-x1.letsencrypt.org/
CP section 4.10.2: OCSP responses from this service must have a maximum expiration time of 10 days.
* Audit: Annual audits are performed by Schellman & Company, Inc., according to the WebTrust criteria.
WebTrust CA:
https://cert.webtrust.org/SealFile?seal=1987&file=pdf
WebTrust BR:
https://cert.webtrust.org/SealFile?seal=1988&file=pdf
*Potentially Problematic Practices:
(
http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain validation to third parties, and Allowing external entities to operate subordinate CAs -- CP section 8.1: In any event, the CA, RAs, CSAs, and CMAs must certify annually that they have at all times during the
period in question complied with the requirements of this Policy. The CA, RAs, and CMAs must also state any periods of non-compliance with this Policy and provide reasons for non-compliance. The period during which the CA issues Certificates shall be divided into an unbroken sequence of audit periods. An audit period must not exceed one year in duration. Whichever scheme is chosen, it must incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.
This begins the discussion of this request from ISRG to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit. 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