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

Eric Rescorla <> Mon, 23 April 2018 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F09A12D87D for <>; Mon, 23 Apr 2018 09:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.395
X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M-NTsYs9trU0 for <>; Mon, 23 Apr 2018 09:51:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0209412D87B for <>; Mon, 23 Apr 2018 09:51:00 -0700 (PDT)
Received: by with SMTP id v64-v6so17977662otb.13 for <>; Mon, 23 Apr 2018 09:50:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=emWTsO0hlm6LqT9W232kVikA4RwbZ7z9oG+AVgC7yxk=; b=lSuDypxqlqHkclbiHKy5dlFI844thxLx6ymYv8pGmp2Ni8j35bhdFdw2MD/epXI8To 942LZRq3QNCvc8eFwTUGX7JYWEjIhQ4IWRbqwEPhVuNRqCmiIFc7eJVCUJW/qhKNDqii 5SSwsKy8IthqIr+jYT19ms4cH2xZPNclXQ5fMvm/mRTqEhzSiSAQNqH66kYloj3P260t sq1sf85bznMbnRfGXGqb2reqFMLq+Q4b9IkNhZ2sQ75rXTFu9mncS/OsEylUcdmJofpt 1CTPbDVZ7yPloVGRm352Gh8+5X1HcYGwfPEQFIywXOVcvvRQdQZr1kaz1QC/a4qJn1Sm oOKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=emWTsO0hlm6LqT9W232kVikA4RwbZ7z9oG+AVgC7yxk=; b=mbnLIj1F6ZXNqo/8hgjawx/fvPkfH+xnn2BOJyTbnoEs7aeZKmXrrjoyyw5LGaCu7d LOx4qqXoLNf4XgVOlS8GFSmcXeEbaLo6SdTgNmXBvHQRTpwOYFmUbR7E+H/ndQ4vcMpv Lm32cvwO41zqAc49zKQBw9bdWBNRlJmkyM5ULboEwyRogZCFaXIo4azFr/fwf89tXOqr vIWZDm1pbE78QhBrla616sSlltCsNrCrzEa5JQc+IkVZP47GAqceydIgjFQGEZEYevUg 7UY8YCpvvAXjM0Zj70aGi35oh0dw65rUAlkrAykiDscS7A7zTdUWMHpI2/eR3JOtV9Oy eU6A==
X-Gm-Message-State: ALQs6tApw6ru3dFWjMOjumE8TyhF/l+la51nN2FbDHv0DvbK8rjtMewZ UwhAahqNIbQhkfEMsIx9emqCU9vs3rqUbyJjrNqqKCGg
X-Google-Smtp-Source: AB8JxZryOXHc0znv+NE74pGEI1WJYnrJqMkKWZYWsoFXmduCS0dkHJIUIkRFsWJXi6d0OdEisBSw0A+2f63YAmTmz0o=
X-Received: by 2002:a9d:334f:: with SMTP id u15-v6mr2854450otd.214.1524502259216; Mon, 23 Apr 2018 09:50:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 23 Apr 2018 09:50:18 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Mon, 23 Apr 2018 09:50:18 -0700
Message-ID: <>
To: Sean Turner <>
Cc: TLS WG <>
Content-Type: multipart/alternative; boundary="0000000000009edc18056a86d758"
Archived-At: <>
Subject: Re: [TLS] early code point assignment for draft-ietf-tls-certificate-compression
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Apr 2018 16:51:02 -0000


On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner <> 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 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