The decision to format the OID this way was an early one that I’m not
completely attached to. That said the existing solution does still feel cleaner
to me than doing the versioning directly under id-pe. Given it’s unlikely that
the version with be incremented by anything other than a document from the ACME
WG, and that doing so is likely to deprecate the existing version it seems more
prudent to me (from a inexperienced position admittedly) for this WG to manage
the assignments of the versioned OIDs under the id-pe-acmeIdentifier arc rather
than have to defer to the registration to the SMI numbers registry.
With that said if there is WG consensus to move to this suggested version I’m
happy to oblige and move forward with it.
> On Aug 14, 2018, at 12:00 PM, Russ Housley <hous...@vigilsec.com> wrote:
>
> This document include a particular object identifier, and IANA has not
> assigned it yet. Please do not assume that you will get the next available
> number. Someone else could get there before you.
>
> This document uses the following syntax for the certificate extension:
>
> id-pe-acmeIdentifier OBJECT IDENTIFIER ::= { id-pe 31 }
>
> id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::= { id-pe-acmeIdentifier 1
> }
>
> acmeValidation-v1 ::= OCTET STRING (SIZE (32))
>
> I see no reason for the middle value. This would cause the creation os an
> additional table for IANA to maintain.
>
> Instead, I suggest using { id-pe 31 } directly for the certificate
> extension. If a v2 is needed in the future, another number from this same
> object identifier arc can be assigned for it.
>
> Russ
> (The IANA Expert for the SMI Security for PKIX Certificate Extension registry)
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
