Re: ISRG Root Inclusion Request
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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
On 6/7/16 9:47 AM, Kathleen Wilson wrote: 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. 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 Thanks again to all of you who have continued to contribute to this 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
On Fri, Jul 1, 2016 at 12:31 PM, Peter Kurrasch 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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
I'm not sure I follow. Why should the inclusion process proceed before the updates are complete? Original Message From: j...@letsencrypt.org Sent: Thursday, June 30, 2016 10:04 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: ISRG Root Inclusion Request 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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. 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. Nope. You can buy a "prepaid" EMV card at a corner store. If you're under-25 it's probably easier to buy a prepaid card than a bottle of liquor in many countries. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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.)From: Matt PalmerSent: Tuesday, June 28, 2016 10:13 PMOn 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 seemto turn up within a minute or so of validating them -- no way a human isconsistently 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 fromLE 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 loveto have the popcorn concession on a discussion about whether to requirepayment for DV certs; I could retire on the proceeds.- Matt___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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 LambSent: Wednesday, June 8, 2016 10:03 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: ISRG Root Inclusion RequestOn 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 d...@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.___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 d...@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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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.Section 1.3.1, para 8, should say certs are issued *to* people *for a* machine because it is people who have the responsibilities, liabilities, and claims concerning this whole process. Besides, it is a person who must demonstrate control over a FQDN, not the machine (or is it?). Also, can the CA revoke a cert for any reason it wants, or only those spelled out by the BR?... 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 w
Re: ISRG Root Inclusion Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
Greetings,
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
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 onlin
Re: ISRG Root Inclusion Request
Kathleen, what is the progress here? Are any queries left over? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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, 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/ > > An updated version of the diagram can be found here: > > https://letsencrypt.org/certificates/ > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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: https://letsencrypt.org/certificates/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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. > > I'm still puzzled as to what "Verified" means in this document. What has been > verified and by who? Mozilla's root inclusion/change request process is described here: 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
Could you provide more details of this violation, please? On Thu, Apr 21, 2016 at 6:14 AM, 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? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ISRG Root Inclusion Request
Referring to the bug tracker entry, where was a recent violation of BR 4.9.1.1. How will ISRG handle that in future? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ISRG Root Inclusion Request
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
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.
ISRG Root Inclusion Request
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
