One small thing I noticed - the CA Hierarchy diagram the bug links to is out of date: https://bugzilla.mozilla.org/attachment.cgi?id=8660928
At a minimum, X3 and X4 now exist: https://letsencrypt.org/certificates/ -- Eric On Wed, Apr 20, 2016 at 4:01 PM, Kathleen Wilson <[email protected]> wrote: > 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 > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
