Subject: Re: [TLS] TLS Errate confirmation

From: Martin Rex <[email-masked]>
Date: Wed, 4 Mar 2009 17:13:33 +0100 (MET)

Eric Rescorla wrote:
> 
> I confirm this is correct.

Sorry for nitpicking, but rather than:

   struct {
       ClientCertificateType certificate_types<1..2^8-1>;
       SignatureAndHashAlgorithm
         supported_signature_algorithms<2^16-1>;
       DistinguishedName certificate_authorities<0..2^16-1>;
   } CertificateRequest;

I believe it should say:

   struct {
       ClientCertificateType certificate_types<1..2^8-1>;
       SignatureAndHashAlgorithm
         supported_signature_algorithms<1..2^16-1>;
       DistinguishedName certificate_authorities<0..2^16-1>;
   } CertificateRequest;

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Mar 2009 17:38:51 +0100 (MET)

>        DistinguishedName certificate_authorities<0..2^16-1>;

The above appears to apply to rfc5246 7.4.4. as well.

I can't see anything in the text that suggests the information
in SignatureAndHashAlgorithms may be left out, so I assume
the length spec should read <1..2^16-1> and not <0..2^16-1>.

Not being a real TLS implementor I had not noticed that the
field SignatureAndHashAlgorithm had been newly added to TLS v1.2
and didn't exist in TLS v1.1.

I'm not particularly happy about a backwards incompatible change
in the (wire) protocol that is _not_ clearly marked as such in the
spec.  Things like this have happend before in the history of
SSLv3 -> TLS v1.2 (e.g. the switch from NO_CERTIFICATE alert to
an empty client certificate message), and I would like to politely
ask that for future spec revisions, the precise difference
of a backwards incompatible changes in the wire format of a
protocol PDU should be described in the TLS specification.  ;-)

-Martin