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