Subject: [TLS] early code point assignment for draft-ietf-tls-certificate-compression

From: Sean Turner <[email-masked]>
Date: Mon, 23 Apr 2018 12:33:08 -0400

All,

tl;dr: If you object to the following early code point assignments 1) add the compress_certificate in the TLS ExtensionType Registry and 2) compressed_certificate in the TLS HandshakeType Registry, then please let the list know why by 2359UTC on 10 May 2018.  The Certificate Compression Algorithm IDs will be populated with two values: zlib and brotli.

At IETF101, we discussed beginning the process of getting an early code point assignment for the extension defined in draft-ietf-tls-certificate-compression.  The one technical comments raised at the meeting was extending the compression code point space from 1 byte to 2 might be a good idea.  The authors have merged a PR to address this in the gh repo and once they submit a new version of the draft the process for an early code point assignment will begin.  The rules for this are specified in RFC7120, and the four criteria for a draft to be eligible for early code point assignment are:

Criteria A

       The code points must be from a space designated as "RFC
       Required", "IETF Review", or "Standards Action".  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC.

The Transport Layer Security (TLS) Extensions and TLS HandshakeType Registry registries are both RFC Required.  While we’re changing that registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still every intention to publish draft-ietf-tls-certificate-compression as an RFC so we’re still good to go.

Criteria B

       The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an Internet-Draft.

When asked at IETF101 what other outstanding comments there were on the draft the only one identified was increasing the code point size for the compression algorithms.  Version -05 will address this point.

Criteria C

       The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

At IETF101, it was noted that this specification was stable enough.  Implementation issues might be identifier later, but, well, that’s the point.

Criteria D

       The Working Group chairs and Area Directors (ADs) judge that
       there is sufficient interest in the community for early (pre-RFC)
       implementation and deployment, or that failure to make an early
       allocation might lead to contention for the code point in the
       field.

5 WG participants all from different organizations indicated their interest in implementing this draft (even if it was just for experimentation).

There are also 6 steps identified in RFC 7120 for early assignment, but only four involve the chairs:

  1.  The authors (editors) of the document submit a request for early
       allocation to the Working Group chairs, specifying which code
       points require early allocation and to which document they should
       be assigned.

An in-person request was made at IETF 101 for the early code point assignments.  There was also an earlier on-list request.

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly
       conditions (c) and (d).

The chairs agree that the four conditions have been met.

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

The sense of the room at IETF 101 was that yes early allocation is appropriate, but this email is verifying that.

   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
       from the Area Director(s).  The Area Director(s) may apply
       judgement to the request, especially if there is a risk of
       registry depletion.

Once the chairs have determined WG consensus, we’ll pass it to Ben.

spt

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Apr 2018 09:50:18 -0700

+1

On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <[email-masked]> wrote:

> All,
>
> tl;dr: If you object to the following early code point assignments 1) add
> the compress_certificate in the TLS ExtensionType Registry and 2)
> compressed_certificate in the TLS HandshakeType Registry, then please let
> the list know why by 2359UTC on 10 May 2018.  The Certificate Compression
> Algorithm IDs will be populated with two values: zlib and brotli.
>
> At IETF101, we discussed beginning the process of getting an early code
> point assignment for the extension defined in draft-ietf-tls-certificate-compression.
> The one technical comments raised at the meeting was extending the
> compression code point space from 1 byte to 2 might be a good idea.  The
> authors have merged a PR to address this in the gh repo and once they
> submit a new version of the draft the process for an early code point
> assignment will begin.  The rules for this are specified in RFC7120, and
> the four criteria for a draft to be eligible for early code point
> assignment are:
>
> Criteria A
>
> The Transport Layer Security (TLS) Extensions and TLS HandshakeType
> Registry registries are both RFC Required.  While we’re changing that
> registry’s rules with draft-ietf-tls-iana-registry-updates, there’s still
> every intention to publish draft-ietf-tls-certificate-compression as an
> RFC so we’re still good to go.
>
> Criteria B
>
> When asked at IETF101 what other outstanding comments there were on the
> draft the only one identified was increasing the code point size for the
> compression algorithms.  Version -05 will address this point.
>
> Criteria C
>
> At IETF101, it was noted that this specification was stable enough.
> Implementation issues might be identifier later, but, well, that’s the
> point.
>
> Criteria D
>
> 5 WG participants all from different organizations indicated their
> interest in implementing this draft (even if it was just for
> experimentation).
>
>
> An in-person request was made at IETF 101 for the early code point
> assignments.  There was also an earlier on-list request.
>
> The sense of the room at IETF 101 was that yes early allocation is
> appropriate, but this email is verifying that.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 23 Apr 2018 18:46:49 +0000

+1

On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla <[email-masked]> wrote:

>> point assignment for the extension defined in
>> draft-ietf-tls-certificate-compression.  The one technical comments raised
>> at the meeting was extending the compression code point space from 1 byte
>> to 2 might be a good idea.  The authors have merged a PR to address this in
>> the gh repo and once they submit a new version of the draft the process for
>> an early code point assignment will begin.  The rules for this are
>> specified in RFC7120, and the four criteria for a draft to be eligible for
>> early code point assignment are:
>>
>> Criteria A
>>
>> every intention to publish draft-ietf-tls-certificate-compression as an RFC
>> so we’re still good to go.
>>
>> Criteria B
>>

---

From: Christopher Wood <[email-masked]>
Date: Mon, 23 Apr 2018 22:20:45 -0500

+1

On Monday, April 23, 2018, David Benjamin <[email-masked]> wrote:

>>> tl;dr: If you object to the following early code point assignments 1)
>>> add the compress_certificate in the TLS ExtensionType Registry and 2)
>>> registry’s rules with draft-ietf-tls-iana-registry-updates, there’s
>>> still every intention to publish draft-ietf-tls-certificate-compression
>>> as an RFC so we’re still good to go.
>>>
>>> Criteria B
>>>

---

From: Alessandro Ghedini <[email-masked]>
Date: Tue, 24 Apr 2018 17:18:18 +0100

> When asked at IETF101 what other outstanding comments there were on the draft the only one identified was increasing the code point size for the compression algorithms.  Version -05 will address th…

Small correction, the code point size change was included in draft-03 (not -05)
that was published yesterday.

Cheers