Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

[Joseph Salowey <[e-mail]>]

Since there is a conflict with deployments with extension code point 26
IANA has now assigned the compress_certificate extension code point 27 from
the TLS extensionType values registry.

On Wed, May 23, 2018 at 6:23 PM, Sean Turner <[e-mail]> wrote:

> IANA has assigned the following values:
>
> 1) In the ExtensionType Values registry, the following entry was added:
>
> 26      compress_certificate (TEMPORARY - registered 2018-05-23, expires
> 2019-05-23)    [draft-ietf-tls-certificate-compression]
>
> Please see
> https://www.iana.org/assignments/tls-extensiontype-values
>
> 2) In the TLS HandshakeType Registry, the following entry was added:
>
> 25      compressed_certificate (TEMPORARY - registered 2018-05-23, expires
> 2018-05-23)  DTLS-OK: Y      [draft-ietf-tls-certificate-compression]
>
> Please see
> https://www.iana.org/assignments/tls-parameters
>
>
>
> NOTE: IANA can’t create the registry for the compression algorithms until
> the document is approved by the IESG, but Ben (and the chairs) figured we
> didn’t really need that to get this going.  If additional compression
> algorithms start to get used, let’s make sure to note what they are.
>
> spt
>
> >> From: Sean Turner <[e-mail]>
> >> Subject: early code point assignment for draft-ietf-tls-certificate-
> compression
> >> Date: April 23, 2018 at 12:33:08 EDT
> >> To: TLS WG <[e-mail]>
> >>
> >> 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
> >
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>