Thank you! Sent from my iPhone
> On Nov 5, 2017, at 11:30 PM, Richard Barnes <[email protected]> wrote: > > > >> On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty >> <[email protected]> wrote: >> 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. > > These changes have been merged into the document. > > https://github.com/ietf-wg-acme/acme/pull/348 > > > >> >> 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
