| 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?
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 | ||||||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
