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

[Corey Bonnell <[e-mail]>]

Hi Aaron,

> It allows multiple components. The top-level ABNF rule is `oid = number *( DOT number )`, allowing arbitrarily-many dot-separated numeric components.

Ah, that was bad phrasing on my part. I was trying to highlight that it allows OIDs consisting of a single component, which is invalid. The ABNF also allows multiple components, as you noted.

> The ABNF you've proposed in the PR looks good to me, though it does still feel ridiculous that there's not a better document to reference for something as seemingly-common as producing an OID.

Thanks for the additional set of eyes, and fully agreed that it feels like something as fundamental as parsing OID strings should already be defined somewhere.

We’ll cut a new version with these fixes in the next day or so.

Thanks,
Corey


________________________________
From: Aaron Gable <aaron=[e-mail]>
Sent: Monday, May 18, 2026 6:52 PM
To: Corey Bonnell <Corey.Bonnell=[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Acme] Re: [IANA #1451549] expert review for draft-ietf-acme-device-attest (acme)

On Mon, May 18, 2026 at 6:42 AM Corey Bonnell <Corey.Bonnell=[e-mail]<mailto:[e-mail]>> wrote:

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<https://url.avanan.click/v2/r01/___https://github.com/ietf-wg-acme/draft-bweeks-acme-device-attest/pull/24___.YXAzOmRpZ2ljZXJ0OmE6bzpmNmQxYzE3MzcxMjAwMTRmZDE3YzM0NTQ3NDI4ZDRjNTo3OjdjNTg6YjE3ODlmMGM2ZmU2YTM3MjJmMTdlNTI2ZTA5YWE0N2ZmYmFkYmY0ZmZmMjI5MWJhNWFiZTY2YzUxZjJiMTRlMjpoOlQ6Rg>



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.

It allows multiple components. The top-level ABNF rule is `oid = number *( DOT number )`, allowing arbitrarily-many dot-separated numeric components.


  1.  It allows any number for the root component. However, the only allowed values are the values 0, 1, and 2 per X.690.

  1.  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.

These are good points. (For the sake of posterity, it is not X.690 which creates these constraints; rather X.690 takes advantage of these constraints to enable a dense packing of the first two components into a single byte. The constraint is established by X.660, Section 6.2.1. And both the constraint itself and the BER/DER encoding taking advantage of it have prior precedent in the X.200 series, but the history there is murkier for me.)

The ABNF you've proposed in the PR looks good to me, though it does still feel ridiculous that there's not a better document to reference for something as seemingly-common as producing an OID.

Thanks,
Aaron