Just to throw in my 1/2 cent. We are using ACME for non-DV certificates in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080: https://www.sipforum.org/download/joint-atissip-forum-standard-signature-based-handling-asserted-information-using-tokens-shaken-governance-model-certificate-management-atis-1000080/?wpdmdl=3360
Regards, Mary. On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty < [email protected]> wrote: > Hello, > > Thank you to the editors and WG for your efforts on > draft-ietf-acme-acme, it's a well written and easy to understand > draft. I do have a few comments, that need to be address by the > editors and SHEPHERD. > > Please review the idnits. There are a few warnings that should be > correctable and can be addressed, but more importantly, it calls out > several downrefs that are not in the shepherd writeup. These need to > be in the writeup and then also mentioned in the IETF last call > announcement (I'll make sure the latter happens). > > Here's my mostly editorial comments: > > Introduction: > It reads very well, but it would be helpful to those unfamiliar with > the work to explicitly state that ACME is about DV certificates. The > first sentence of the last paragraph seems like the best place to add > this in. > Current text: > This document describes an extensible framework for automating the > issuance and domain validation procedure, thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > Proposed: > This document describes an extensible framework for automating the > issuance and domain validation procedure for DV certificates, > thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > > I do like how the introduction is framed as it’s clear the level of > security provided by the certificates issued via ACME. Thanks for > that. > > The introduction should also make it clear that ACME can be used for > other services using DV certificates, not just HTTP. This is > mentioned in the Terminology section, but I think a clear sentence > upfront would be helpful. > > Section 2: Nit/suggestion: Change the tense to read as a published RFC > in the last paragraph, last sentence (take it or leave it). > Current: > Such close integration of ACME with HTTPS > servers would allow the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > Proposed: > Such close integration of ACME with HTTPS > servers allows the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > > IANA Section: > Everything looks good except that RFC5226 has been obsoleted, so the > new reference is RFC8126 and “specification required” > https://tools.ietf.org/html/rfc8126#section-4.6 still means the same > thing, so using that is fine. > > Security considerations: > I think it would be good to mention here that they are DV certs so the > reader understands from he introduction and this section the level of > cert issued through ACME and doesn’t assume a higher level of > assurance. > > s/ACME is a protocol for managing certificates/ACME is a protocol for > managing DV certificates/ > > 10.1 - I know this is obvious to the people in the WG, but a reference > to RFC7525 to properly configure TLS 1.2 should be included to protect > against the mentioned attacks. If you want to also reference TLS 1.3 > and specify no 0-RTT that would be good too. It’d be great to see > this get widely deployed, so there may be a number of newcomers > reading this to make their lives easier with cert > issuance/maintenance. > > 10.2 - what if the server that the account verifier has an account on > (client for ACME) is compromised and is used to request new > certificates or perform other actions? I think this is one of the > larger risks, so mentioning this is possible and hardening measures > should be taken to prevent compromise would be prudent. Hardening > measures or appropriate security controls should be broadly understood > terms (I think) so that you wouldn’t need to list out things like > turing off unnecessary services. > > 10.5 - I would think you’d see requests for new phishing domains > rather than known ones through this process. What would you look for > there as that’s a complex problem - it would be hard to know all legit > names to know if one was a play off of the original. This happened > with equifax - they provided a site name with a typo and a ‘white hat’ > attacker had set up a site that looked just like theirs at that site. > But it was announced by equifax. Tough problem as automating a check > on the DNS registration may not detect something unusual, but maybe > recommending this check could help? RDP lessens what needs to be > shared from whois though, although I don’t think that’s widely > deployed. > > -- > > Best regards, > Kathleen > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
