Inline,,, On 9/24/25, 2:14 AM, "Laurence Lundblade" <[email protected] <mailto:[email protected]>> wrote:
<snip> > My only problem with the nomenclature for acme-device-attest is that it will > attract people looking for remote attestation, and fail to attract people who > want device authentication. > > Abstract says: > } This document specifies new identifiers and a challenge for the > } Automated Certificate Management Environment (ACME) protocol which > } allows validating the identity of a device using attestation. > > and a clue should be the lack of the word **remote** before attestation. > It's authentication, or even authorization, but not attestation. I can’t tell where acme-device-attest is coming from / going to yet. They do seem to be deconstructing WebAuthN to get the attestation part out. I don’t like the total lack of discussion of attestation key material. [CW] I don't think I'd say there is a " total lack of discussion of attestation key material." It's just incorporated by reference. WebAuthn does cover attestation keys, albeit maybe not to the depth you'd like to see. I don’t know why they aren’t using EAT, or at least allowing it. It seems some of the fields they are defining might overlap with EAT. [CW] Re: why, I'd guess timeline and fielded support (but don't know). Re: "why aren't they allowing EAT", is there anything preventing someone from registering EAT as a "defined attestation statement format" per RFC 8809? Seems like they should do a lot more work to explain themselves (to us). <snip> _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
