I don't really think it matters much who's going to make a new version.
The only difference here is whether you go back to IANA to get a new code
point. Given that the IANA process is not onerous, it seems like the extra
couple of octets are not really adding anything here. So I'm inclined to
do as Russ suggests and just have future versions in the same ARC as
opposed to having a separate version field. Like Roland, however, I don't
feel super strongly about this.
--Richard
On Tue, Aug 14, 2018 at 5:18 PM Roland Shoemaker <rol...@letsencrypt.org>
wrote:
> 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
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
