[Acme] Re: [IANA #1451549] expert review for draft-ietf-acme-device-attest (acme)

[Corey Bonnell <[e-mail]>]

Hi Aaron,

Thank you for another careful review of the document. We have proposed fixes to address the three concerns in this PR: https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/24

 

The first two items are straightforward, and the fixes should be obvious. However, the third is more complex.

 

I reviewed the ABNF for object identifiers in RFC 3061 and believe it is defective in several ways:

 

1.	It allows only one component. Per X.208 and subsequent updates, at least two components are required.
2.	It allows any number for the root component. However, the only allowed values are the values 0, 1, and 2 per X.690.
3.	It allows any number for the second component. However, if the root component is 0 or 1, then the second component must be between 0-39 decimal. Several DER parsers also enforce that the second component be between 0-39 even when the root component is 2, but that is more restrictive than what is prescribed by X.690. I have no objection to modifying the ABNF to enforce this, since it’s highly unlikely there will be real-world breakage and would simplify the grammar by doing so.

 

With all this in mind, I came up with a modified ABNF that considers all the above and resolves the leading 0 issue that you pointed out.

 

When I get a few spare cycles, I’ll likely file an erratum for RFC 3061 to fix these issues, unless anyone knows of a reason why RFC 3061 is fine as-is.

 

Thanks,

Corey

 

From: Aaron Gable <aaron=[e-mail]> 
Sent: Friday, May 15, 2026 7:23 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Acme] Re: [IANA #1451549] expert review for draft-ietf-acme-device-attest (acme)

 

Hi David,

 

I have a few comments, but all are minor and I expect they can easily be addressed in a new draft version as part of IETF Last Call.

 

1. The draft declares a new entry `badAttestationStatement` to be added to the ACME Error Types registry. However, the body of the draft never specifies when an ACME Server SHOULD or MUST return this new error type.

 

2. Typo: the draft says that the above entry should be added to the "ACME Error Type" registry; it is actually named the "ACME Error Types" (note the plural) registry. This sentence also doesn't have the same structure/syntax as the nearly-identical sentences in the two previous sections, but that's more of a style nit.

 

3. The document registers two new identifier types (hardware-module and permanent-identifier), and provides instructions for how to encode them both in ACME requests and in x.509 certificates. However, the ABNF provided for doing so appears to reinvent the wheel: the "assigner-value" and "hw-type-value" ABNF tags are intended to represent OIDs, but RFC 3061 already defines a (slightly different!) ABNF syntax for matching OIDs. I suggest that the authors normatively reference that ABNF instead, as the draft's current ABNF includes bugs like allowing leading zeroes.

 

Assuming these minor fixes are made, the IANA registrations look good to me.

 

Thanks,

Aaron

 

On Fri, May 15, 2026 at 12:35 PM David Dong via RT <[e-mail] <mailto:[e-mail]> > wrote:

Hi Richard, Aaron,

Just a follow-up on this; thank you!

Best regards,

David Dong
IANA Services Sr. Specialist

On Wed May 06 21:47:26 2026, david.dong wrote:
> Hi Richard, Aaron,
> 
> Just to note, you had previously reviewed -01 of this document and
> provided feedback; there looks to be a new Validation Method in -04
> and changes to the document.
> 
> Thank you.
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Wed May 06 21:41:11 2026, david.dong wrote:
> > Dear Richard Barnes, Aaron Gable (cc: acme WG),
> >
> > As the designated experts for the ACME Identifier Types, ACME
> > Validation Methods and ACME Error Types registries, can you review
> > the
> > proposed registrations in draft-ietf-acme-device-attest-04 for us?
> > Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ <https://url.avanan.click/v2/r01/___https:/datatracker.ietf.org/doc/draft-ietf-acme-device-attest/___.YXAzOmRpZ2ljZXJ0OmE6bzo5YjE3MjFkNGQwZmQzZjAzYjUzOThhNWM3ZmZjNDI0Yjo3OmFiNzA6MDYyNGVhZDAzYjYyODRhYzAyOTMwN2ZlNWI2M2MzNDRlOGZjNzdmOTI5M2NjYjJjYTQ2ZDg0MGZjN2U5NmRmYTpoOlQ6Rg> 
> >
> > The due date is May 20th.
> >
> > If this is OK, when the IESG approves the document for publication,
> > we'll make the registrations at:
> >
> > https://www.iana.org/assignments/acme/ <https://url.avanan.click/v2/r01/___https:/www.iana.org/assignments/acme/___.YXAzOmRpZ2ljZXJ0OmE6bzo5YjE3MjFkNGQwZmQzZjAzYjUzOThhNWM3ZmZjNDI0Yjo3OmUzYTI6YWZkOTA2ZjlhODdhMDNlZTg1NmVhMTc3ZTQ4ZWM4ZWVlN2Y2Y2YwNjAyNGJlMzY5MmVkMTRlMDIzODZkNGY3NDpoOlQ6Rg> 
> >
> > When the review is complete (or, if you have concerns that need to be
> > addressed, when the initial review is complete), we'll update the
> > Datatracker's "IANA expert review" state and send any comments to the
> > authors. Unless you ask us to wait for other reviewers, we'll act on
> > the first review we receive.
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Sr. Specialist