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

[Aaron Gable <[e-mail]>]

On Mon, May 18, 2026 at 6:42 AM Corey Bonnell <Corey.Bonnell=
[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
>
>
>
> 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