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]
