> > > Is there any chance we'll get through this review so I can start last > call this week?
I think it is premature to start last-call. There are *no* full implementations of the current draft (as far as I am aware) and experience from attempting a complete implementation has highlighted a problem[0] that will require protocol adjustment. [0] - https://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51vg On Mon, Oct 2, 2017 at 5:03 PM, Kathleen Moriarty < [email protected]> wrote: > Hello, > > Is there any chance we'll get through this review so I can start last > call this week? In order to have it on the last telechat before > Singapore, we'd need to have an update ready for me to start last > call. Thanks to those who gave feedback on my DV cert questions. > > Thanks, > Kathleen > > On Fri, Sep 22, 2017 at 6:03 PM, Kathleen Moriarty > <[email protected]> wrote: > > 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 > > > > -- > > 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
