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) 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. 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. 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)) typos, etc. 1. Section 3, para 1: KMIP, spell this out somewhere. I think you only use this once... Deb Cooley [email protected] Pronouns: she/her
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
