I thought this draft was pretty easy to follow, and I just have a few minor comments. Note: I am probably reviewing this from the point of view of an integrator (maybe?) definitely not as a device developer, and not as a CA developer.
Section 1, sentence after bullets and Section 4, paragraph 1: Section 1 used “enrolment” while Section 4 used “enrollment”. Pick one. Use it everywhere. Section 3, 4 and 5 call flow: both cases show the ACME CA returning a PEM, while the EST RA returns a PKCS#7 to the device. Is this intentional? Are you expecting the EST Server to convert the certificate from PEM to PKCS 7, and is the PKCS7 a .p7b or .p7c. [note: these are trivial conversions, but they are also very confusing to most people] >From an architecture point of view, do you expect the EST Server to be run by the requesting organization? Or by the CA owner – or is this not even possible? [from a ‘domain control’ point of view] Again architecture: If the EST Server sits in front of a large organization, then domain validation is more interesting, and the Get /csrattrs may or may not be able to recommend a SAN, right? I can see that policy oids could be provided, if that is a thing in these systems. [we use policy oids in US DOD, but that is possibly uncommon elsewhere.] Section 8.1, para 3: What does ‘The cache should be keyed by the complete contents of the CSR’ mean? The word ‘keyed’, I think, is the problem. Maybe ‘indexed’? Unless the cache is encrypted? Deb Cooley, NSA
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
