Thanks for the input and the offline message, Mary. An offline process is needed from what I can tell to use ACME for anything considered a higher assurance than a DV cert, is that right? If so, I think it's important to make that clear with a simple sentence.
Thank you, Kathleen Sent from my iPhone > On Sep 22, 2017, at 5:33 PM, Clint Wilson <[email protected]> wrote: > > An additional 1/2 cent from me; we intend to use ACME primarily, if not > solely, with non-DV certs. > > >> On Fri, Sep 22, 2017, 2:51 PM Mary Barnes <[email protected]> wrote: >> 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
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
