One additional point.  The same IANA process would be used to get object 
identifiers for subsequent versions.  The difference is which table the value 
comes from.

Russ


> On Aug 15, 2018, at 11:10 AM, Richard Barnes <[email protected]> wrote:
> 
> 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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
> > <mailto:[email protected]>> 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
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/acme 
> > <https://www.ietf.org/mailman/listinfo/acme>
> 
> _______________________________________________
> Acme mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/acme 
> <https://www.ietf.org/mailman/listinfo/acme>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to