Kathleen, Here are a few comments, let me know if you have questions/concerns/etc. I'd be happy to clarify.
Deb Cooley [email protected] 0. So the trick here is in the original ACME spec, they could rely on DNS registration, as yucky as it is (w/out DNSSEC), at least it exists. In the client space, you don't have anything like DNS, nor do you really want it (privacy, tracking end users, etc.). But you need something instead. The question is what? If you can punt this issue to be out of scope, then the rest is easy. But if you punt it, then is this I-D really necessary? 1. Section 2, first para: I would delete the phrase, 'As with the TLS certificates defined in the core ACME document'. It is ambigious (is it defined in RFC 8555 or is it not defined?). 2. Section 2: This appears to be basically a reiteration of SP 800-63. Is this common? because these standards are freely available. You don't appear to be selecting a level, so I'm not sure what the point is. If I were the author, I'd take most of this out. 3. Section 3: None of those things are immutable (IP address, hostname, MAC address). We (DOD) have to work pretty hard to enroll devices the first time. For names, we use things like S/N. Rekey, once we have a device key/cert in place is much easier. Usually, we have to have a human in the loop, at least the first time. Again, you could punt this part.... 4. Section 3: EST is an open standard. Where the target is device enrollment, right? 5. Section 4, para 1: Storage of the certificate isn't really an issue. Storage of the private key is an issue. Don't know that I'd say 'browser', perhaps 'browser, O/S key store, or PKCS#11 container'. How many end users use a KMIP container? [I'm thinking none of them] 6. Section 4, para 1: I wouldn't use the word 'presumably'. I'd say 'intended to be' instead. 7. Section 5: Frankly, I don't think code signing certificates should be issued automatically. The issuance of these needs to be intentional. If I were the author, I'd delete this. 8. Section 6: Where is SMS and email defined to be an additional challenge type? I don't believe SMS messages are allowed as a challenge/response mechanism in SP 800-63. Because SMS notifications do not normally require a mobile platform to be unlocked to view. 9. Section 7.1.3: This section looks like a direct copy and paste of Section 7.1. Is that really necessary? 10. Section 7.2: In general, I don't like the fact that 'certificates' is used alone when it is the 'private key/certificate pair' is actually being used. Perhaps this could be called the public key cryptography section? 11. Section 7.2, sentence 2: replace 'acceptable for the specified process and then stored appropriately' with 'acceptable for the specified process and the private key stored appropriately'. 12. Section 7.3: I'm not terribly familiar w/ FIDO. Do they use certificates? Or just bare public/private key pairs (like SSH)? Grammar/spelling (just as I see them) 1. Intro: Code SIgning should be code signing. 2. Section 6: administrors should be administrators. 3. Section 7.2, first sentence: identiying should be indentifying. 4. Section 7.2, sentence 2: posisble should be possible. 5. Section 7.3: typos regisration sb registration, puiblic sb public. On Sun, Nov 3, 2019 at 10:00 AM Thomas Peterson <[email protected]> wrote: > Asides from a typo nit you have introduced acknowledging Tim "Thank you > tp Tim..." you draft looks good. > > Regards > > On 01/11/2019 15:50, Kathleen Moriarty wrote: > > Hello, > > > > I posted an update of > > https://datatracker.ietf.org/doc/draft-moriarty-acme-client/ > > <https://datatracker.ietf.org/doc/draft-moriarty-acme-client/> that > > includes a few updates per Tim Hollebeek's review. > > > > Additional comments and reviews appreciated! > > > > -- > > > > Best regards, > > Kathleen > > > > _______________________________________________ > > Acme mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
