Thanks MCR and Aaron, So what concrete change are we suggesting that the authors make to the document? (I want to keep aware here that this draft represents an already-deployed technology, but we have lost participation from the deployers, so we should be careful about making interop-affecting changes at this stage, which might just amount to "SHOULD" instead of "MUST")
I _think_ the suggestion to the authors is that the document needs to be modified so that: 1. It specifies a JSON structure for carrying the new permanent-identifier and harward-module identifiers in an ACME order object. 2. It specifies how those are translated into X.509 SANs. 3. It specifies that these SHOULD be ignored in the CSR that comes with the finalize message. On Sun, 8 Mar 2026 at 11:08, Aaron Gable <aaron= [email protected]> wrote: > I concur with Michael. In my opinion, every draft of this shape needs to > define three things: > - how you represent the identifier in the ACME protocol > - how you represent the identifier in x509 (usually just a reference to > some other RFC) > - how you demonstrate control over the identifier > > Representing the identifier in the CSR is (currently, but see my previous > posts about getting rid of the finalize CSR) a necessary but not sufficient > condition for issuance. The identifier MUST be representable within the > ACME protocol itself, so it can appear in new-order requests, and in > authorization responses. The server needs to know exactly what identifier > it is validating before it can do so. The finalize CSR appears much too > late for that. > > Aaron > > On Sat, Mar 7, 2026, 08:56 Michael Richardson <[email protected]> > wrote: > >> >> Mike Ounsworth <[email protected]> wrote: >> > From my reading of the PR / draft, it links to [RFC4043 >> > <https://www.rfc-editor.org/rfc/rfc4043>] for the specification of >> a CSR >> > attribute for PermanentIdentifier, and to [RFC4108 >> > <https://www.rfc-editor.org/rfc/rfc4108>] for the specification of >> a CSR >> > attribute for HardwareModuleName. >> >> > I don't know the right answer here, but I think I know the right >> question, >> > which is: is it actually helpful to specify two different ways to >> carry >> > these identifiers in an ACME request; one inside the CSR and one in >> the >> > ACME JSON? >> >> Two places have the interoperability challenge/possible-security issue of >> what happens when they are different. Do all parties consistently use the >> correct one, and if they don't, does this lead to some kind of exploit? >> (The secondary question is what is the comparison function, is a human >> ever >> involved, and if so, could the human approve one the one that says >> Ounswörth, >> while the CA issues Ounsworth?) >> >> I believe that the attributes need to be part of the challenge, such that >> the >> server can see that the resulting WebAuthN response contains the right >> thing. >> The CSR has *not* been transmitted yet. So you can't remove that part. >> >> The document says that including it in the CSR is optional, and that it >> would >> be ommitted if the resulting certificate would not have those attributes. >> (I think that the CA can also remove them by it's own policy) >> >> > I see three possible ways to resolve this situation: >> >> > #1 Delete the ACME JSON mechanism -- this is what Sven's PR is >> attempting >> > (but I agree that it doesn't currently delete it completely from the >> > document). >> >> I think it's just wrong. >> >> > #2 Delete the CSR mechanism -- this would mean fully removing all >> > references to [RFC4032] and [RFC4108] and instead defining new JSON >> > structures. >> >> I see no reason to do this either. >> >> >> -- >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
