Hello Deb, Thank you for taking the time to review the draft again. I'll respond in line and update the draft accordingly.
On Tue, Sep 28, 2021 at 6:52 AM Cooley, Dorothy E <deco...@nsa.gov> wrote: > Kathleen, > > Thank you for updating the client draft. This is a rough and quick review, > just to get things started: > > 1. Section 3, para 1: Storage of certificates is trivial (they are > public), storage of private keys is more important. Is this too pedantic? > (note: this confusion of certificates and private keys continues through > the draft, not just in this paragraph) > I made a few adjustments. I think the reason I was focused on certificates is that the request in ACME sets the correct bits in the certificate. You are correct though and not too pedantic. > 2. Section 3, []: Isn't this why we need identity credential (i.e. the > key > and certificate)? An authentication challenge doesn't 'test the identity > of > the user', but using the identity credential is supposed to chain back to > the fact that the identity of the user was validated. > What change are you recommending? Identity proofing isn't always done back to a user, it is sometimes just authenticating a consistent credential tied to a consistent entity behind that and that entity may never have gone through identity proofing. The credential used in the challenge may not be the key and certificate, it could be something else as is done for other challenge/responses in ACME. > 3. Section 4: I will freely admit that code signing certificates makes me > extremely twitchy (my own biases at play). Of all the things that could be > automated, I would choose this one last. I haven't had a chance to look at > the current state of CA/Browser Forum requirements for code signing > certificates, OV (organizational validation), or EV wrt code signing. My > personal opinion is that we should tread carefully here. I would be > curious > to see what use case needs this. And who would consider implementing. I'm > going to pass on comments this time around. It's already being used in this way. If you think about, the purist view prevented us from implementing automated certificate management for many years. Then, after Snowden, there was a willingness to allow it. We had a jump to 30% adoption of web server encryption following Snowden. As a result in the years following, ACME became an option and the automation and free certificates brought us to somewhere around 90%. If we want code signing to be ubiquitous, we need to make it easier. SOme will choses a more trustworthy path and some will be stringent about the authentication process behind an automated process. This will likely tie into SBOM in time, I'd like to see us get to a high rate of adoption for SBOM, ideally with in-person identity proofing for the credentials used in the process to get code signing certificates. If you look at the process in use today, it's not really different from what's described, we just need to really encourage the use of a solid process prior to the automated part. This will let us have shorter lifetimes on code signing and could even consider single use, etc. It would be really useful to get to the point where we could allowlist all software expected on a system (including libraries within applications) to enable the ability to flag unexpected software. SBOM may enable that and could get us away from deny list approaches of AV and threat indicators. If it's not easy as well as secure, we won't get there. > > > 4. Section 5: SMS is only mentioned once in RFC 8555 as a notification > method - for a user to go back and collect the completed certificate. I > don't see where it is listed as an allowed pre-authorization challenge > method. (Note: collection of an issued certificate is not the same as > holding the complete credential (private key and certificate)) > Noted, I removed SMS. Thank you for catching that! I'll post a new version. Best regards, Kathleen > > typos, etc. > > 1. Section 3, para 1: KMIP, spell this out somewhere. I think you only > use this once... > Thank you! I expanded a few other acronyms as well. I appreciate your helpful review. Best regards, Kathleen > > Deb Cooley > deco...@nsa.gov > Pronouns: she/her > > > -- Best regards, Kathleen
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
