Sorry about getting to this > On Jun 8, 2021, at 16:15, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > Owen Friel \(ofriel\) <ofriel=40cisco....@dmarc.ietf.org> 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.
CMC does define a Modify Certification Request Control (see https://datatracker.ietf.org/doc/html/rfc5272#section-6.5.1). Whether that is implemented is another story. > 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
