Did anyone see this? Or did it get lost in the shuffle? Deb Cooley
On Fri, Mar 19, 2021 at 6:46 AM Deb Cooley <debcool...@gmail.com> wrote: > 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
