Re: [Acme] draft-ietf-acme-tls-alpn-03

[Russ Housley]

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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] draft-ietf-acme-tls-alpn-03

[Richard Barnes]

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

Re: [Acme] draft-ietf-acme-tls-alpn-03

[Roland Shoemaker]

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  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] draft-ietf-acme-tls-alpn-03

[Russ Housley]

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