On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes <[email protected]> wrote: > > > 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.
You're essentially saying the same thing with this text, so I'm fine with it. The introduction describing cert types and then not having any statements about what is automated and what might need additional non-automated process is an important link to make, so thanks. Kathleen > > 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 > > -- Best regards, Kathleen _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
