Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt

[Sean Turner <[e-mail]>]

> On Jan 26, 2018, at 05:26, Alessandro Ghedini <[e-mail]> wrote:
> 
> Me and Victor would like to ask for early codepoints assignment again, if you
> think we are ready now.

This now on the chair’s list of things to do.  It’s been a week and nobody has complained so I’m thinking the draft is on the right track.   Got one question before we start the RFC7120-dictated early code point assignment dance:

Q. What’s the plan for the dictionary?  Is a field going to be included later to indicate which one is in use, or is the dictionary going to be linked to the extension number and a new one will be minted when the dictionary is updated?



I got some other minor nits (I’ll submit them in GH but thought I’d include them here as well):

0) s4: includes the following:

   If the format of the Certificate message is altered using the
   server_certificate_type extension [RFC7250], the resulting altered
   message is compressed instead.

Shouldn’t it also mention client_certificate_type?

1) Is it worth expanding a bit on the text quoted above to note that it’s more than just altering the message it’s also about changing how the authentication messages are computed?  E.g., CertificateVerify is now Transcript-Hash(Handshake Context, CompressedCertificate).

2) Likewise, is it worth noting that in TLS 1.3 currently using compression on CertificateType.RawPublicKey is not going yield much in the way of compression?  Is it worth saying that future values of CertificateType should indicate whether compression is a good idea or not?

3) s7.3: to match the table:

OLD:

   The values in this registry shall be allocated under "IETF Review"
   policy for values strictly smaller than 64, and under "Specification
   Required" policy otherwise (see [RFC8126] for the definition of
   relevant policies).

NEW:

   The values in this registry shall be allocated under "IETF Review"
   policy for values strictly smaller than 64, under "Specification
   Required" policy for values 64-223, and under “Private Use”
   otherwise (see [RFC8126] for the definition of relevant policies).

4) s7.3: probably worth adding how to get one under the spec required:

   The procedures for requesting values in the Specification Required
   space are specified in [ID.tls-iana-registry-updates].

Our AD/IANA will ask later who is the expert (experts are implied as part of Spec Required), so how about we use the existing expert pool.

Note that the above 4 nits I don’t think really affect whether the early code point assignment starts.

spt