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

From: Russ Housley <[email-masked]>
Date: Tue, 14 Aug 2018 15:00:17 -0400

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)

---

From: Roland Shoemaker <[email-masked]>
Date: Tue, 14 Aug 2018 14:17:38 -0700

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-masked]> wrote:
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Aug 2018 10:51:11 -0400

Since the document includes:

I have asked IANA to make this assignment.  It made this request to avoid a future conflict.

I do not see any value in another table subordinate to this value.

Russ

> On Aug 14, 2018, at 5:17 PM, Roland Shoemaker <[email-masked]> wrote:
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Aug 2018 11:10:15 -0400

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-masked]>
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.
>
> > 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.
> >
> > 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

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Aug 2018 11:14:46 -0400

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-masked]> 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-masked] <mailto:[email-masked]>> wrote:
> > On Aug 14, 2018, at 12:00 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Aug 2018 15:18:37 +0000

Everything can be solved by an extra level of indirection, but in this case I agree that there is no need for a new sub-arc.