Hello Deb, Thank you for the note and the comments, all points noted, yes we will review and work through them along the IETF LC.
Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Deb Cooley <[email protected]> Sent: Monday, May 4, 2026 04:22 To: [email protected] <[email protected]> Cc: <[email protected]> <[email protected]>; IETF ACME <[email protected]> Subject: AD comments on draft-ietf-acme-device-attest CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. First-time / External Recipient Warning You have not previously corresponded with this sender. Thanks for the work to improve this draft! I have several pretty easy comments. I will put this draft into IETF Last Call, with the assumption that my comments will be worked before/together with IETF Last Call comments. Section 1, para 3: 'is to be' is an odd turn of phrase, how about 'will be'? Section 3.1, assigner value: Is this intended to be an IP address? If so, expect to get a comment similar to 'what about IPv6 addresses?' If it is intended to be an OID, then I would just say that, as is done in Section 4.1. Section 3.2, title: Add (CSR). Or within para 4, spell out CSR instead. Section 3.2 and 4.2, para 3 and 4: 'octet-for-octet', I'm curious to hear why any other sort of 'match' isn't correct or useful. And why merely saying that it 'MUST be a match' wouldn't work. Section 6.1, para 1: nit: remove '###External Account Binding'. Section 6.1.1, para 2: This wording isn't clear (I had to read it a bunch of times to understand). How about something like, 'Servers can rely on other authorization mechanisms,such as external account binding or pre-authorized accounts, to establish device identity instead of completing the device-attest-01 challenge.' Deb Cooley Sec AD
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
