Yes Deb, it did get lost in the shuffle. See inline.
From: Acme <[email protected]> On Behalf Of Deb Cooley Sent: 19 March 2021 18:46 To: [email protected] Cc: Cooley, Dorothy E <[email protected]> Subject: [Acme] comments on: draft-ietf-acme-integrations-03.txt 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. [ofriel] Sure, will fixup. 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] [ofriel] That’s a fair point. We could reference https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2 and state that EST server may request ACME certs using "application/pkcs7-mime" and that would avoid a transcoding operation when the EST downloads the cert from ACME. 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] [ofriel] We think this should be run by the organization that owns the domain, and then the EST RA can request certs from the ACME CA which could be run by a different org. 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.] [ofriel] That is also a fair point, for complex deployments its not clear what policy the EST server may want to apply before assigning a SAN. The text in section 3 currently states: “EST servers could use this mechanism to tell the client what fields to include in the CSR Subject and Subject Alternative Name fields” We could beef up that statement and explicitly state that the policy by which the EST determines the SAN to specify is explicitly out of scope. And also note that policy OIDs could be provided. 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? [ofriel] Yes “indexed” is better and less confusing. Deb Cooley, NSA
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
