info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ISRG Root Inclusion Request
1,752 views
Skip to first unread message
Kathleen Wilson
Apr 20, 2016, 4:01:18 PM4/20/16
to mozilla-dev-s...@lists.mozilla.org
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
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
Eric Mill
Apr 20, 2016, 5:57:36 PM4/20/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
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 <kwi...@mozilla.com>
wrote:
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
konklone.com | @konklone <https://twitter.com/konklone>
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 <kwi...@mozilla.com>
wrote:
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
konklone.com | @konklone <https://twitter.com/konklone>
neg...@gmail.com
Apr 21, 2016, 12:46:35 PM4/21/16
to mozilla-dev-s...@lists.mozilla.org
Referring to the bug tracker entry, where was a recent violation of BR 4.9.1.1. How will ISRG handle that in future?
Richard Barnes
Apr 21, 2016, 12:53:09 PM4/21/16
to neg...@gmail.com, mozilla-dev-s...@lists.mozilla.org
Could you provide more details of this violation, please?
On Thu, Apr 21, 2016 at 6:14 AM, <neg...@gmail.com> wrote:
> Referring to the bug tracker entry, where was a recent violation of BR
> 4.9.1.1. How will ISRG handle that in future?
On Thu, Apr 21, 2016 at 6:14 AM, <neg...@gmail.com> wrote:
> Referring to the bug tracker entry, where was a recent violation of BR
> 4.9.1.1. How will ISRG handle that in future?
Nick Lamb
Apr 21, 2016, 2:37:02 PM4/21/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 20 April 2016 21:01:18 UTC+1, Kathleen Wilson wrote:
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8727954
In this document "Note requesting EV treatment" probably should read "Not requesting EV treatment" since, as I understand it and the rest of the summary makes clear, ISRG is a DV-only CA.
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8727954
I'm still puzzled as to what "Verified" means in this document. What has been verified and by who?
Kathleen Wilson
Apr 22, 2016, 9:03:15 PM4/22/16
to mozilla-dev-s...@lists.mozilla.org
On Thursday, April 21, 2016 at 11:37:02 AM UTC-7, Nick Lamb wrote:
> On Wednesday, 20 April 2016 21:01:18 UTC+1, Kathleen Wilson wrote:
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8727954
>
> In this document "Note requesting EV treatment" probably should read "Not requesting EV treatment" since, as I understand it and the rest of the summary makes clear, ISRG is a DV-only CA.
Thanks for catching the typo. I fixed it in Salesforce.
> On Wednesday, 20 April 2016 21:01:18 UTC+1, Kathleen Wilson wrote:
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8727954
>
> In this document "Note requesting EV treatment" probably should read "Not requesting EV treatment" since, as I understand it and the rest of the summary makes clear, ISRG is a DV-only CA.
>
> I'm still puzzled as to what "Verified" means in this document. What has been verified and by who?
https://wiki.mozilla.org/CA
"3. A representative of Mozilla verifies the information provided by the CA."
In this case (as in most cases), I verified the information provided by the CA, according to the checklist, https://wiki.mozilla.org/CA:Information_checklist
The file that you references is created from Salesforce, which is where I indicate which items I have verified, or need further clarification from the CA, etc.
Kathleen
Nick Lamb
Apr 22, 2016, 10:34:13 PM4/22/16
to mozilla-dev-s...@lists.mozilla.org
On Saturday, 23 April 2016 02:03:15 UTC+1, Kathleen Wilson wrote:
> In this case (as in most cases), I verified the information provided by the CA, according to the checklist, https://wiki.mozilla.org/CA:Information_checklist
Thanks again Kathleen. This makes more sense to me now.
> In this case (as in most cases), I verified the information provided by the CA, according to the checklist, https://wiki.mozilla.org/CA:Information_checklist
josh...@gmail.com
May 1, 2016, 7:15:55 PM5/1/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, April 20, 2016 at 4:57:36 PM UTC-5, Eric Mill wrote:
> 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/
An updated version of the diagram can be found here:
> 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/
https://letsencrypt.org/certificates/
Richard Barnes
May 2, 2016, 9:37:11 AM5/2/16
to Aas, Josh, mozilla-dev-s...@lists.mozilla.org
Josh: Do you guys intend to issue certificates for the X3 and X4 CAs under
the ISRG root?
As it stands, they're not immediately relevant to the ISRG root inclusion
request, since they're only signed by IdenTrust.
On Sat, Apr 30, 2016 at 4:12 PM, <josh...@gmail.com> wrote:
> On Wednesday, April 20, 2016 at 4:57:36 PM UTC-5, Eric Mill wrote:
the ISRG root?
As it stands, they're not immediately relevant to the ISRG root inclusion
request, since they're only signed by IdenTrust.
On Sat, Apr 30, 2016 at 4:12 PM, <josh...@gmail.com> wrote:
> On Wednesday, April 20, 2016 at 4:57:36 PM UTC-5, Eric Mill wrote:
> > 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/
>
> > out of date:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8660928
> >
> > At a minimum, X3 and X4 now exist:
> > https://letsencrypt.org/certificates/
>
jo...@letsencrypt.org
May 2, 2016, 11:28:01 AM5/2/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, May 2, 2016 at 8:37:11 AM UTC-5, Richard Barnes wrote:
> Josh: Do you guys intend to issue certificates for the X3 and X4 CAs under
> the ISRG root?
>
> As it stands, they're not immediately relevant to the ISRG root inclusion
> request, since they're only signed by IdenTrust.
We intend to sign X3 and X4 with the ISRG root before the end of the year.
> Josh: Do you guys intend to issue certificates for the X3 and X4 CAs under
> the ISRG root?
>
> As it stands, they're not immediately relevant to the ISRG root inclusion
> request, since they're only signed by IdenTrust.
Jason -
May 23, 2016, 6:24:20 PM5/23/16
to mozilla-dev-s...@lists.mozilla.org
Kathleen, what is the progress here? Are any queries left over?
Andrew R. Whalley
Jun 6, 2016, 8:55:05 PM6/6/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Greetings,
Here are the notes from my review.
Certification Practice Statement
Updated May 5, 2016
Copyright Notice:
"This document is provided for the intended recipient’s review only. Do
not copy, electronically reproduce,
reprint, or utilize this document, in part or in whole, unless prior
written consent is obtained from ISRG."
This isn't in keeping with a public document.
Section 1.1:
"In addition, the practices described in this CPS comply with the
CA/Browser Forum (CAB
Forum) Baseline Requirements, version 1.1.9"
The baseline requirements are currently at version 1.3.4
Section 1.3.2
"Practice Statement that describe in detail how the CA implements the
CA/B Forum Baseline Requirements,
currently version 1.3.3,"
The baseline requirements are currently at version 1.3.4
Section 3.2.2.1
Final sentence of the section ends with a comma. Assuming it’s meant to
be a full stop, rather than there being text missing.
Section 9.16.5
“The operation of the Internet is beyond ISRG’s reasonable control.” :-)
Section 6.3.2
The table lists the certificate lifetime of the Root CA and Intermediate
CA as 20 years and 6 years respectively. Section 10 lists 25 years and 8
years. Though they do match section 6.3.2 in the CP.
Section 10.2
“ISRG Domain Validated TBD”
Looks like it's 1.3.6.1.4.1.44947.1.1.1
General notes:
Sometimes there’s an explicit distinction made between DV-SSL and
Administrative when talking about subscribers, but not always. Might be
helpful to make it clear that any time there isn't a distinction made it
applies to both.
It might be useful to have any requirements explicitly specified in a
section of BRs to be called out in the corresponding section (even if it's
just referencing another section). For example, BRs 5.4.3. “The CA SHALL
retain any audit logs generated for at least seven years.” but that's
actually covered in section 5.5.1 of the CPS.
Certificate Policy
Version 1.2
Updated May 5, 2016
Approved by ISRG Policy Management Authority
ISRG
Same comment about the copyright notice.
--
While it would be good to see these issues addressed in future updates to
the documents, none are serious.
Andrew
On Wed, Apr 20, 2016 at 1:01 PM, Kathleen Wilson <kwi...@mozilla.com>
Here are the notes from my review.
Certification Practice Statement
Internet Security Research Group (ISRG)
Version 1.4
Updated May 5, 2016
Copyright Notice:
"This document is provided for the intended recipient’s review only. Do
not copy, electronically reproduce,
reprint, or utilize this document, in part or in whole, unless prior
written consent is obtained from ISRG."
This isn't in keeping with a public document.
Section 1.1:
"In addition, the practices described in this CPS comply with the
CA/Browser Forum (CAB
Forum) Baseline Requirements, version 1.1.9"
The baseline requirements are currently at version 1.3.4
Section 1.3.2
"Practice Statement that describe in detail how the CA implements the
CA/B Forum Baseline Requirements,
currently version 1.3.3,"
The baseline requirements are currently at version 1.3.4
Section 3.2.2.1
Final sentence of the section ends with a comma. Assuming it’s meant to
be a full stop, rather than there being text missing.
Section 9.16.5
“The operation of the Internet is beyond ISRG’s reasonable control.” :-)
Section 6.3.2
The table lists the certificate lifetime of the Root CA and Intermediate
CA as 20 years and 6 years respectively. Section 10 lists 25 years and 8
years. Though they do match section 6.3.2 in the CP.
Section 10.2
“ISRG Domain Validated TBD”
Looks like it's 1.3.6.1.4.1.44947.1.1.1
General notes:
Sometimes there’s an explicit distinction made between DV-SSL and
Administrative when talking about subscribers, but not always. Might be
helpful to make it clear that any time there isn't a distinction made it
applies to both.
It might be useful to have any requirements explicitly specified in a
section of BRs to be called out in the corresponding section (even if it's
just referencing another section). For example, BRs 5.4.3. “The CA SHALL
retain any audit logs generated for at least seven years.” but that's
actually covered in section 5.5.1 of the CPS.
Certificate Policy
Version 1.2
Updated May 5, 2016
Approved by ISRG Policy Management Authority
ISRG
Same comment about the copyright notice.
--
While it would be good to see these issues addressed in future updates to
the documents, none are serious.
Andrew
On Wed, Apr 20, 2016 at 1:01 PM, Kathleen Wilson <kwi...@mozilla.com>
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
>
> 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
>
> https://bugzilla.mozilla.org/attachment.cgi?id=8727954
>
Kathleen Wilson
Jun 7, 2016, 12:47:48 PM6/7/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, April 20, 2016 at 1:01:18 PM UTC-7, Kathleen Wilson 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
>
Thank you to everyone who has reviewed and commented on this request from ISRG to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit.
> 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
>
There is an open request for ISRG to fix a few things in the next version of their CP/CPS, but none of the items are show stoppers. And I believe that all of the other questions have been resolved.
Therefore, I plan to close this discussion and recommend approval in the bug.
Thanks,
Kathleen
jo...@letsencrypt.org
Jun 7, 2016, 1:25:05 PM6/7/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, June 6, 2016 at 7:55:05 PM UTC-5, Andrew R. Whalley wrote:
> Greetings,
>
> Here are the notes from my review.
Thanks Andrew, we will address these.
> Greetings,
>
> Here are the notes from my review.
Peter Kurrasch
Jun 8, 2016, 8:56:44 AM6/8/16
to mozilla-dev-s...@lists.mozilla.org
I have comments as well. I made it to only Section 3.2.1 before I decided I have too many concerns about Let's Encrypt to include in a review of the CPS. I'll raise them in a separate thread, so here are my comments on just this CPS document.
General Comments:
* I'd like to echo what Andrew brought up about separating out the DV-SSL certs from other certs to be covered by this CPS. Doing so throughout the doc will make it cleaner, but Section 3.2 would definitely benefit.
* I would like to see more of a distinction made between human actors and machines. Machines and such can be compromised more readily than humans so the extent to which machines are performing some of these functions will greatly dictate what the attack surface looks like.
* I'd like to see an updated CPS submitted for review before we decide to proceed with inclusion of the Let's Encrypt root.
Specific comments:
Section 1.1 needs to mention ACME since that is a key feature (benefit?) of Let's Encrypt. This is essential because the success (or failure) of Let's Encrypt depends on the security (or vulnerability) of ACME. A reference should be made to an RFC or other fixed specification (i.e. no Internet-Drafts or doc on github that is still being updated).
Section 1.2.2 has a lot of words to say, basically, there is one ID and a bunch of "other" stuff that is left unspecified and unidentified. Will ISRG create new cert types without updating the CPS? I think it would be clearer to instead state exactly what is being done now and the respective OIDs.
... para 12, does not explain how exactly the CA will enter into a "relying party agreement" with each relying party on the Internet, and how the CA will be able to document that the terms were actually agreed upon...with every relying party. (See also my comments for Section 1.3.5.)
Section 1.3.3 the word "combination" requires the use of and, not or. Is an implication to be made that ISRG might contract out RA work to an organization that is composed exclusively of intelligent computational entities?
Section 1.3.4 would be better to separate out the applicant from subscriber, since they are defined as having separate responsibilities a la Section 1.6.1. For example, an applicant can not ask the CA to revoke a cert.
Section 1.3.4 Item 1 has poor grammar; plus, applicant should verify and accept/reject all certs, not only those with the applicant named in them.
... Item 2 has poor grammar and needs to explain what an unaffiliated subscriber is. What is the distinction to be made between applicants and subscribers and representatives? Are all of them human?
... Item 5 shouldn't say a RA is responsible for revocation if that's not cited as a responsibility in 1.3.3.
... In addition, an "it" can not notify a CA that a cert should be revoked. An "it" is unable to make claims and thus can not forfeit them for failure to comply with anything. Also, this section is an introduction so why all the fine details?
... The second Item 4 hardly seems necessary ("the subscriber is obligated to not screw up"). Plus this seems relevant to only the DV-SSL certs not the others that ISRG might want to issue.
... The second Item 5 and Item 6 shouldn't say that revoking a cert necessitates throwing away your key pair. Also the list of situations is hardly complete.
... And Item 8 has an interesting list of criminal activities. So ISRG cares about these uses of certs that chain to their root? What criteria do they have in mind to identify those activities? This item should at least agree with what's stated in Section 1.4 if not just referencing that section outright.
Section 1.3.5 says a relying party might be an organization but that doesn't make sense to me. What use case does ISRG envision wherein they might enter into an agreement with an organization? Quite apart from that question, however, is the problem that this whole section, as written, is wildly impractical and unenforceable. What is the intention for this section?
Section 1.3.6 doesn't make sense: each participant in the PKI should be identified explicitly and not lumped together under a category of "other".
Section 1.3.6.1 should explain what is meant by manufacture in this context, why it merits identification as a distinct entity, and why it would make any sense for ISRG to contract that work out to someone else.
Section 1.3.6.2 doesn't make sense. A repository is a thing, not a participant. It's something that a CA does, except for when it doesn't do it. I'm not sure I'm altogether comfortable with ISRG saying they won't even maintain the repository themselves. It makes me wonder what they are left doing?
Section 1.4.1 para 1 is laughable: of course a SSL/TLS cert will be used for SSL/TLS comms! Maybe it would be better to say something about how many domains may appear per cert, especially if there is a special feature or circumstance about this CA or ACME that might limit that number. Also, no mention of wildcard certs?
Section 1.4.2 makes no mention of malware, "furtherance of criminal enterprises", etc. The note seems to be using "relying party" in an inconsistent way or else I totally missed the point.
Section 1.4.3 para 2, if the trust relationship is not accepted, no cross-signed cert would be issued, would it?
Section 1.6.1, acceptance, is a mess. Is this definition intended to address only the applicant? Why would the Relying Party Agreement come into play? How can "failing to notify the CA" possibly be an indication of acceptance? Will the CA "imply" acceptance or is it an explicit act? I'm also troubled with "other" because it suggests that something I do might get interpreted by ISRG as acceptance even though I did not intend it as such.
... CMA is not actually a definition.
... domain name registrant, will the CA be contacting registrars directly or relying solely on WHOIS data? If the WHOIS lists a privacy or anonymization service, how is the registrant identified?
... reasonable reliance seems to rehash or redefine Section 1.3.5. Keep it simple here, elaborate there.
Section 3.1.2 has a reference error.
Section 3.1.5 uses unique in an imprecise way. A subscriber may have multiple certs for multiple machines/domains. Also, a unique subject may have multiple certs associated with it if certs are revoked, reissued, rekeyed, etc.
Section 3.2.1 is where this whole thing falls apart for me. I am not familiar with the ACME protocol nor the ACME client so this is the first time I'm seeing that the client might be running on a different machine than the one getting the cert. This raises all sorts of security concerns.
This section is also the first place I've seen a non-ACME procedure being mentioned. So does this mean ISRG will support both mechanisms when requesting a new cert? Perhaps more should be said in the introduction about ISRG's intentions?
| Original Message | |
| From: Kathleen Wilson Sent: Tuesday, June 7, 2016 11:47 AM Subject: Re: ISRG Root Inclusion Request |
On Wednesday, April 20, 2016 at 1:01:18 PM UTC-7, Kathleen Wilson 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
>
>
> 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
>
Thank you to everyone who has reviewed and commented on this request from ISRG to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit.
There is an open request for ISRG to fix a few things in the next version of their CP/CPS, but none of the items are show stoppers. And I believe that all of the other questions have been resolved.
Therefore, I plan to close this discussion and recommend approval in the bug.
Thanks,
Kathleen
There is an open request for ISRG to fix a few things in the next version of their CP/CPS, but none of the items are show stoppers. And I believe that all of the other questions have been resolved.
Therefore, I plan to close this discussion and recommend approval in the bug.
Thanks,
Kathleen
Nick Lamb
Jun 8, 2016, 11:03:47 AM6/8/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 8 June 2016 13:56:44 UTC+1, Peter Kurrasch wrote:
> Section 3.2.1 is where this whole thing falls apart for me. I am not familiar with the ACME protocol nor the ACME client so this is the first time I'm seeing that the client might be running on a different machine than the one getting the cert. This raises all sorts of security concerns.
How so? As you correctly observed the subscriber is not a machine but a person, and the ACME process obtains reasonable confidence this person (whether through the operation of one machine, two machines as is common or dozens of machines in some complicated scenarios) is only issued with certificates for names they control.
> Section 3.2.1 is where this whole thing falls apart for me. I am not familiar with the ACME protocol nor the ACME client so this is the first time I'm seeing that the client might be running on a different machine than the one getting the cert. This raises all sorts of security concerns.
Consider the mundane situation of a customer of a traditional commercial CA. Perhaps Dave Cameron. Dave wishes to obtain a certificate for the name www.example.com, and so he uses a laptop, machine #1 to view pages from the CA's web server, machine #2, he types www.example.com into a web form, picks a few items from lists, types in his credit card details. After a while, email is sent to the address da...@example.org, which is the WHOIS admin contact for the example.com 2LD, the email asks to confirm that Dave wants the certificate issued. This email is delivered somehow to the example.org mail server (machine #3) and Dave views it on his iPhone (machine #4). Dave clicks "Yes, confirm" and duly receives the certificate.
This everyday process for issuing DV certificates involves four machines outside the Certificate Authority systems themselves, none of which is www.example.com, and the process achieves its confidence as to Dave's legitimate control of www.example.com by a rather circuitous route, but it has been accepted as "good enough" and goes unremarked upon in applications to these trust stores. ACME is, if anything, simpler and more robust in its assurance, your lack of familiarity with it aside. If you object already to the status quo then an inclusion request thread is the wrong place to do that.
You also seem confused by the existence of Administrative Certificates, which are needed for infrastructure. The document already lists examples of Administrative Certificates such as OCSP responders, and the intermediates for issuing leaf certificates to end users. They aren't some sort of alternative to ACME for end users.
Peter Kurrasch
Jun 28, 2016, 10:53:11 PM6/28/16
to mozilla-dev-s...@lists.mozilla.org
Apologies for the delay in responding...it got lost amongst the other things on my plate.
I'll answer the easier question first: admin certs. I wasn't so much confused by their presence in the CPS as I was discontent with the similar-but-different manner in which they were discussed. I think keeping them separate from the DV-SSL cert discussions will limit ambiguity and confusion.
As for my "different machine" comment, I wasn't very clear so I'll try to fix that. I'm not actually concerned with the number of machines involved in obtaining a cert, but I do wonder what might happen when one of them becomes compromised. In an ACME setting I think the consequences could be worse than the status quo/traditional setting, but it's more accurate to say I just can't tell. I would need to review a more complete spec than I was able to find before I could draw any real conclusions.
At issue is the degree to which automation is featured in the operating model of the Let's Encrypt CA. Fast, easy, cheap, and with little chance for human intervention or oversight...that's a recipe for abuse. If ACME means that I, as the bad guy, can compromise one machine and start getting certs issued to me for my nefarious purposes, then I'm a huge fan and Let's Encrypt will be my go-to source for certs. If instead ACME makes it harder for me to do that, then I'll be sad but it's probably a boon to Internet security.
I know there are other comments I've made that probably deserve scrutiny and fleshing out so I hope people will feel free to speak up and let me know.
| From: Nick Lamb Sent: Wednesday, June 8, 2016 10:03 AM Subject: Re: ISRG Root Inclusion Request |
On Wednesday, 8 June 2016 13:56:44 UTC+1, Peter Kurrasch wrote:
> Section 3.2.1 is where this whole thing falls apart for me. I am not familiar with the ACME protocol nor the ACME client so this is the first time I'm seeing that the client might be running on a different machine than the one getting the cert. This raises all sorts of security concerns.
How so? As you correctly observed the subscriber is not a machine but a person, and the ACME process obtains reasonable confidence this person (whether through the operation of one machine, two machines as is common or dozens of machines in some complicated scenarios) is only issued with certificates for names they control.
Consider the mundane situation of a customer of a traditional commercial CA. Perhaps Dave Cameron. Dave wishes to obtain a certificate for the name www.example.com, and so he uses a laptop, machine #1 to view pages from the CA's web server, machine #2, he types www.example.com into a web form, picks a few items from lists, types in his credit card details. After a while, email is sent to the address da...@example.org, which is the WHOIS admin contact for the example.com 2LD, the email asks to confirm that Dave wants the certificate issued. This email is delivered somehow to the example.org mail server (machine #3) and Dave views it on his iPhone (machine #4). Dave clicks "Yes, confirm" and duly receives the certificate.
This everyday process for issuing DV certificates involves four machines outside the Certificate Authority systems themselves, none of which is www.example.com, and the process achieves its confidence as to Dave's legitimate control of www.example.com by a rather circuitous route, but it has been accepted as "good enough" and goes unremarked upon in applications to these trust stores. ACME is, if anything, simpler and more robust in its assurance, your lack of familiarity with it aside. If you object already to the status quo then an inclusion request thread is the wrong place to do that.
You also seem confused by the existence of Administrative Certificates, which are needed for infrastructure. The document already lists examples of Administrative Certificates such as OCSP responders, and the intermediates for issuing leaf certificates to end users. They aren't some sort of alternative to ACME for end users.
Consider the mundane situation of a customer of a traditional commercial CA. Perhaps Dave Cameron. Dave wishes to obtain a certificate for the name www.example.com, and so he uses a laptop, machine #1 to view pages from the CA's web server, machine #2, he types www.example.com into a web form, picks a few items from lists, types in his credit card details. After a while, email is sent to the address da...@example.org, which is the WHOIS admin contact for the example.com 2LD, the email asks to confirm that Dave wants the certificate issued. This email is delivered somehow to the example.org mail server (machine #3) and Dave views it on his iPhone (machine #4). Dave clicks "Yes, confirm" and duly receives the certificate.
This everyday process for issuing DV certificates involves four machines outside the Certificate Authority systems themselves, none of which is www.example.com, and the process achieves its confidence as to Dave's legitimate control of www.example.com by a rather circuitous route, but it has been accepted as "good enough" and goes unremarked upon in applications to these trust stores. ACME is, if anything, simpler and more robust in its assurance, your lack of familiarity with it aside. If you object already to the status quo then an inclusion request thread is the wrong place to do that.
You also seem confused by the existence of Administrative Certificates, which are needed for infrastructure. The document already lists examples of Administrative Certificates such as OCSP responders, and the intermediates for issuing leaf certificates to end users. They aren't some sort of alternative to ACME for end users.
Matt Palmer
Jun 28, 2016, 11:13:59 PM6/28/16
to dev-secur...@lists.mozilla.org
On Tue, Jun 28, 2016 at 09:52:59PM -0500, Peter Kurrasch wrote:
> At issue is the degree to which automation is featured in the operating
> model of the Let's Encrypt CA. Fast, easy, cheap, and with little
> chance for human intervention or oversight...that's a recipe for abuse.
Every CA that I've ever used automates DV issuance. My DV certs always seem
> At issue is the degree to which automation is featured in the operating
> model of the Let's Encrypt CA. Fast, easy, cheap, and with little
> chance for human intervention or oversight...that's a recipe for abuse.
to turn up within a minute or so of validating them -- no way a human is
consistently doing meaningful checks in there. ACME isn't the issue either;
most other CAs have (hideous) APIs to make requests automatic.
The only difference here between LE and every other CA is that issuance from
LE is free. While it's not a meaningful speedbump for the modern criminal,
it does at least mean they've got to find a stolen CC. Personally, I'd love
to have the popcorn concession on a discussion about whether to require
payment for DV certs; I could retire on the proceeds.
- Matt
Peter Kurrasch
Jun 29, 2016, 8:39:16 AM6/29/16
to Matt Palmer, dev-secur...@lists.mozilla.org
I agree that ACME alone is not the issue, so many of the criticisms I would levy against it apply equally well to other, more proprietary interfaces that the other CA's use (and I do commend ISRG for taking the open and transparent route). For that matter, are existing CA's required to undergo frequent security scans/reviews of their interfaces, both browser-based and otherwise? Do we know that their websites pass even the most basic pen-tests? As the bad guy, I hope the answer is no.
Personally I see ease and ubiquity as more appealing than the cost. It's easy and cheap to get a stolen credit card number so cost isn't much of a deterrent to the bad actor. But you'd still have get one so a free cert is an easy cert and, thus, more appealing.
(You might want to dust off your popcorn machine in case we need it.)
Nick Lamb
Jun 29, 2016, 1:08:18 PM6/29/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, 29 June 2016 04:13:59 UTC+1, Matt Palmer wrote:
> The only difference here between LE and every other CA is that issuance from
> LE is free.
Nope. StartSSL and WoSign offer free issuance, Comodo offers a free "trial" which would be perfectly good for criminal enterprise. Symantec has a partner deal which is free at point of use, I'm sure I missed others, in effect free DV is the baseline product today.
> The only difference here between LE and every other CA is that issuance from
> LE is free.
Let's Encrypt is different in two significant ways, (1) they're a not-for-profit which eliminates the profit motive that has driven CA behaviours which were variously unsafe for the web PKI or terrible for subscribers; (2) they implement an IETF standards track mechanism for issuance
> While it's not a meaningful speedbump for the modern criminal,
> it does at least mean they've got to find a stolen CC.
jo...@letsencrypt.org
Jun 30, 2016, 11:04:45 PM6/30/16
to mozilla-dev-s...@lists.mozilla.org
On Wednesday, June 8, 2016 at 7:56:44 AM UTC-5, Peter Kurrasch wrote:
> I have comments as well. I made it to only Section 3.2.1 before I decided I have too many concerns about Let's Encrypt to include in a review of the CPS. I'll raise them in a separate thread, so here are my comments on just this CPS document.
Hi Peter,
> I have comments as well. I made it to only Section 3.2.1 before I decided I have too many concerns about Let's Encrypt to include in a review of the CPS. I'll raise them in a separate thread, so here are my comments on just this CPS document.
We've reviewed your feedback, much of it is helpful. Thanks. We'll work on incorporating improvements based on it into the next revision of our CPS. We don't believe any of these items need to block inclusion, however.
--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
Peter Kurrasch
Jul 1, 2016, 3:31:33 PM7/1/16
to jo...@letsencrypt.org, mozilla-dev-s...@lists.mozilla.org
I'm not sure I follow. Why should the inclusion process proceed before the updates are complete?
Original Message
From: jo...@letsencrypt.org
Sent: Thursday, June 30, 2016 10:04 PM
Original Message
From: jo...@letsencrypt.org
Sent: Thursday, June 30, 2016 10:04 PM
On Wednesday, June 8, 2016 at 7:56:44 AM UTC-5, Peter Kurrasch wrote:
> I have comments as well. I made it to only Section 3.2.1 before I decided I have too many concerns about Let's Encrypt to include in a review of the CPS. I'll raise them in a separate thread, so here are my comments on just this CPS document.
Hi Peter,
We've reviewed your feedback, much of it is helpful. Thanks. We'll work on incorporating improvements based on it into the next revision of our CPS. We don't believe any of these items need to block inclusion, however.
--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
We've reviewed your feedback, much of it is helpful. Thanks. We'll work on incorporating improvements based on it into the next revision of our CPS. We don't believe any of these items need to block inclusion, however.
--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
Ryan Sleevi
Jul 1, 2016, 3:46:52 PM7/1/16
to Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org, jo...@letsencrypt.org
On Fri, Jul 1, 2016 at 12:31 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
> I'm not sure I follow. Why should the inclusion process proceed before the updates are complete?
Because the concerns you have raised are not requirements of the
> I'm not sure I follow. Why should the inclusion process proceed before the updates are complete?
Mozilla CA Inclusion Policy, nor do they appear to be part of the
Baseline Requirements.
At more fundamental question is whether the concerns you raised
present risk to relying party communities. While you personally may
feel they do, I'm not sure that's a reasonable conclusion, but I'm
still working through your feedback as well to see whether it's
reasonable. As you can see from the list, others have disagreed with
some of your concerns, and I concur with them.
Kathleen Wilson
Jul 18, 2016, 7:39:46 PM7/18/16
to mozilla-dev-s...@lists.mozilla.org
discussion. I appreciate all of the thorough reviews of this request.
There have been additional suggestions that this CA should take under
consideration in the next version of their CP/CPS. However, I have not
seen any questions/concerns that are show-stoppers for this request. It
appears that this CA is in compliance with the current BRs and Mozilla's
CA Certificate Policy.
Therefore, I intend to proceed with closing this discussion and
recommending approval in the bug.
Thanks,
Kathleen
Kathleen Wilson
Jul 20, 2016, 7:01:48 PM7/20/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, July 18, 2016 at 4:39:46 PM UTC-7, Kathleen Wilson wrote:
> Therefore, I intend to proceed with closing this discussion and
> recommending approval in the bug.
Thanks to all of you who participated in this discussion about the request from ISRG to include the "ISRG Root X1" root certificate, and turn on the Websites trust bit.
> Therefore, I intend to proceed with closing this discussion and
> recommending approval in the bug.
I am not aware of any issues that would prevent us from moving forward with this request. Therefore, I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=1204656
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages