It's not so much an offline process as it is an out-of-band process from ACME for the ACME client to get the Service Provider code token that it uses for the challenge. But, perhaps what you're asking for is a statement in the intro that talks about DV certificates being most common? The primary difference between how we use ACME is the identifier validation, where for SHAKEN it's the Service Provider Code token.
Regards, Mary. On Fri, Sep 22, 2017 at 5:03 PM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> 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 <clint.t.wil...@gmail.com> > 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 <mary.ietf.bar...@gmail.com> > 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 < >> kathleen.moriarty.i...@gmail.com> 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 >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
