Thanks Aaron and Daniel. I have copied the summary and links to Daniel's previously-opened issuens into the github PR: https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/13
On Mon, 9 Mar 2026 at 13:20, Daniel McCarney <[email protected]> wrote: > I agree 100% with Aaron. > > This is also feedback I provided on the issue tracker of the draft ( > draft-bweeks-acme-device-attest#9 > <https://github.com/brandonweeks/draft-bweeks-acme-device-attest/issues/9>, > draft-bweeks-acme-device-attest#10 > <https://github.com/brandonweeks/draft-bweeks-acme-device-attest/issues/10>) > back in July. > > > > On Mon, Mar 9, 2026 at 12:10 AM Aaron Gable <aaron= > [email protected]> wrote: > >> Almost exactly, clarifications inline: >> >> On Sun, Mar 8, 2026, 19:33 Mike Ounsworth <[email protected]> >> wrote: >> >>> 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. >>> >> >> Yes. >> >> 2. It specifies how those are translated into X.509 SANs. >>> >> >> Yes. (Which will appear in both the CSR and in the resulting certificate.) >> >> 3. It specifies that these SHOULD be ignored in the CSR that comes with >>> the finalize message. >>> >> >> It should specify that, like any other identifier type, the CA MUST >> verify that the identifiers provided in the CSR exactly match the >> identifiers provided in the new-order request. >> >> Aaron >> _______________________________________________ >> 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]
