Deb in your govt PKI world then, would the flow be something like:
There is no CSR Attributes exchange that allows the RA to tell the Pledge to use a particular CN/SAN. Pledge sends CSR with, say, SAN=serialnumberx RA sends newOrder with identifier= serialnumberx ACME CA decides that the identity should be “serialnumberx.devices.some-gov-dept.example.org” (e.g. based on the RA identity) ACME returns an authorization challenge for “serialnumberx.devices. some-gov-dept.example.org” to the RA. The RA must then prove ownership of that DNS domain before the ACME CA will issue the cert. This is how we envisaged the enterprise/civilian workflow: RA owns the domain e.g. devices.ra.example.org Pledge connects to RA using its IDevID and sends CSR Attributes request RA extracts serial#=abc123 (or whatever) from IDevID and appends domain to it RA tells pledge in CSR Attributes response to include e.g. SAN=abc123.devices.ra.example.org in CSR Pledge sends CSR with SAN= abc123.devices.ra.example.org RA sends newOrder with identifier= abc123.devices.ra.example.org ACME returns an authorization challenge for abc123.devices.ra.example.org RA proves ownership of abc123.devices.ra.example.org and ACME issues cert. (or using acme-subdomains, proves ownership of devices.ra.example.org) From: Deb Cooley <[email protected]> Sent: 10 June 2021 17:52 To: Michael Richardson <[email protected]> Cc: Owen Friel (ofriel) <[email protected]>; [email protected]; Cooley, Dorothy E <[email protected]> Subject: Re: [Acme] comments on: draft-ietf-acme-integrations-03.txt Michael, In my world (government PKI systems), the RA doesn't get to do that. Either the CSR is accepted or it is rejected. The CA has a profile it follows, if the CSR is missing things, the CA adds them before the certificate is signed. The RA can do none of that. In our case, most RAs are actually people, so there can be a back channel to the requestor which can be used to sort it all out. How this all happens in the case of 'little things', I don't know. We do have a 'portal' for devices, but it would probably be quite 'heavy' for your use cases. On Tue, Jun 8, 2021 at 4:15 PM Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: Owen Friel \(ofriel\) <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
