On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < [email protected]> wrote:
> Hi Richard, > > On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <[email protected]> wrote: > > > > > > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty > > <[email protected]> wrote: > >> > >> Hi Richard, > >> > >> Thanks for posting the diff, I reviewed the changes and they look > >> good, but I have a couple of questions. FYI - I had started looking > >> at the PR, but something came up, sorry for the delay and this was a > >> good reminder. > >> > >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <[email protected]> wrote: > >> > Hi Kathleen, > >> > > >> > Thanks for the review. Some responses inline. I've started a PR to > >> > respond > >> > to these comments here: > >> > > >> > https://github.com/ietf-wg-acme/acme/pull/345 > >> > > >> > I agree with Daniel that we should hold off on IETF LC until we've > >> > addressed > >> > the issues around proactive issuance / caching of CSRs. That may > >> > require a > >> > re-WGLC, but once that's closed, it should be safe to send to IETF LC. > >> > > >> > > >> > On Fri, Sep 22, 2017 at 4: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. > >> > > >> > > >> > As others have pointed out, ACME is not just about DV. PR has some > >> > clarification on this point. > >> > >> I see the text on uses in other PKI contexts in the introduction, but > >> don't see anything on the certificate types and out-of-band processes > >> (as is the case for the STIR use case Mary mentioned). Maybe I'm > >> missing it, can you tell me where to look? > > > > > > I don't think you're missing anything. What do you mean by "certificate > > types and out-of-band processes"? How is that different from "other PKI > > contexts"? > > I think by PKI-context, you mean the application of use, is that > right? I am separating out the type of certificate (DV, EV, etc.) as > you have done in the second paragraph of the introduction. When > reading the rest of the document, there isn't text that says what type > of certificate ACME produces without any additional processes > (out-of-band authentication/validation). If you think about > administrators who operate servers (whatever the protocol) or even > those who may wish to incorporate ACME into a new application, they > will may have to figure out what level ACME provides as a default and > also know that there can be additional processes added to obtain > certificates types at a higher assurance level using ACME. Since the > text already does a nice job of explaining the certificate types, this > should be an easy follow up that I think will be very helpful to > people outside of the IETF or who look at this in the future. > > Maybe something like the following: > > Strictly following the automation enabled by ACME, DV certificates > are issued. > Additional processes can be provided by the CA to increase the level of > validation on an end entity to issue certificates at a higher > assurance level, > for instance an EV certificate. <Then maybe provide a reference to the > STIR > example Mary mentioned in this thread.> > > Does that help? Thinking about this in former roles and having been > to some conferences lately, I think being explicit about this will > help those trying to evaluate and deploy ACME. They may look for > providers who meet the assurance levels they need knowing there are > options and understanding the baseline provided by this spec. > It's wrong to frame this as being about assurance levels -- you seem to be presuming that manual processes can give higher assurance than automated ones, a fact which I think has been repeatedly proven false in the web PKI. But I'm fine clarifying that certain things (like EV validation) have not yet been audited: +ACME can also be used to automate some aspects of certificate management even +where non-automated processes are still needed. For example, the external +account binding feature (see {{external-account-binding}}) can be used to +associate authorizations with an account that were not validated through the +ACME authorization process. This allows ACME to address issuance scenarios that +cannot yet be fully automated, such as the issuance of Extended Validation +certificates. Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 --Richard > > Thanks, > Kathleen > > > > > > > >> > >> > > >> > > >> >> > >> >> 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. > >> > > >> > > >> > Done. > >> > > >> > > >> >> > >> >> 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. > >> > > >> > > >> > Updated reference. > >> > > >> > > >> >> > >> >> 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/ > >> > > >> > > >> > Given the discussion about DV, I don't think this change is > appropriate. > >> > > >> > > >> >> > >> >> 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. > >> > > >> > > >> > I don't see how TLS configuration plays into the security > considerations > >> > for > >> > ACME. How you use the certificates you get from ACME is your > business, > >> > and > >> > indeed, several of the envisioned applications have nothing to do with > >> > TLS > >> > (e.g., the email and STIR use cases). > >> > > >> > That said, I have added some language to suggest that ACME servers > >> > should > >> > follow the advice in RFC 7525. 0xRTT should be safe here, because > there > >> > are > >> > anti-replay protections at the application layer. > >> > >> Can you add a pointer in your text about the provided anti-replay > >> protections in the application layer? > > > > > > Draft PR here: > > > > https://github.com/ietf-wg-acme/acme/pull/348 > > > > --Richard > > > > > >> > >> > >> Thanks, > >> Kathleen > >> > >> > > >> > > >> >> > >> >> 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. > >> > > >> > > >> > Added a brief note. > >> > > >> > > >> >> > >> >> 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. > >> > > >> > > >> > This is a policy question, not one for the issuance protocol. > >> > > >> > --Richard > >> > > >> > > >> >> > >> >> > >> >> -- > >> >> > >> >> Best regards, > >> >> Kathleen > >> >> > >> >> _______________________________________________ > >> >> Acme mailing list > >> >> [email protected] > >> >> https://www.ietf.org/mailman/listinfo/acme > >> > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > > > -- > > Best regards, > Kathleen >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
