Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt
Owen Friel \(ofriel\) wrote: deb> Again architecture: If the EST Server sits in front of a large deb> organization, then domain validation is more interesting, and the deb> Get /csrattrs may or may not be able to recommend a SAN, right? I deb> can see that policy oids could be provided, if that is a thing in deb> these systems. [we use policy oids in US DOD, but that is possibly deb> uncommon elsewhere.] ofriel> That is also a fair point, for complex deployments its not clear ofriel> what policy the EST server may want to apply before assigning a ofriel> 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” ofriel> We could beef up that statement and explicitly state that the ofriel> policy by which the EST determines the SAN to specify is ofriel> explicitly out of scope. And also note that policy OIDs could be ofriel> provided. I would love to hear from operators and designers of CAs about how a RA can communicate to the CA about things it doesn't like, or wishes to add, to a certificate request. The CSR is immutable, being signed by the EE requesting. ACME doesn't provide any out-of-CSR mechanism, nor does CMC or CMP (correct me if I'm wrong here!)... Max and I talked a lot about this when design RFC8995, and we had to conclude that it was simply non-standard. In the case of ACP (RFC8994) use of BRSKI, like the Ford Model-T, the CSR may contain anything the Pledge wants to put in, it will get an otherName containing the encoded ACP IPv6 ULA. In implementing, I also realized that the GET /csrattrs is pseudo-idempotent. When first called, it needs to allocate an IPv6 ULA for that node, and it needs to store it, such that whenever the same IDevID does the GET, it gets the same answer. It's uncomfortable having to change database state on a GET, but at least the result is cachable! In the ACME integrations, we haven't said how the RA will decide what dNSName SAN will be returned, but the same property will apply. The RA needs to collect a CSR that it can pass along up ACME, and for which is can do dns-01 challenges. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt
Yes Deb, it did get lost in the shuffle. See inline. From: Acme On Behalf Of Deb Cooley Sent: 19 March 2021 18:46 To: acme@ietf.org Cc: Cooley, Dorothy E 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
