Re: [TLS] certificate type negotiaiton in draft-ietf-tls-oob-pubkey-06

["Hannes Tschofenig" <[e-mail]>]

Hi Nikos, 

thanks for your review comments and for spotting a bug. 

In the current draft a single structure is used by both the client and the server to convey information about the "certificate" types they accept and they offer. 

You suggest to encode this information into two different types of payloads and that is similar to what we had in an earlier draft version (see http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04). The feedback we got at the summer IETF meeting was that this approach was not preferred. Consequently, we changed it. 

Regarding your remark "Why sbd suggest 0,3 and the server reply with 1,2?". I believe the symbolic names are more intuitive for end users who read the specifications and the semantic is explained in the text. A program does not care what numbers are used for the different options. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Sun, 02 Dec 2012 08:57:07 +0100
> Von: Nikos Mavrogiannopoulos <[e-mail]>
> An: [e-mail]
> CC: [e-mail], Hannes Tschofenig <[e-mail]>
> Betreff: certificate type negotiaiton in draft-ietf-tls-oob-pubkey-06

> Hello,
>  There is a bug in the draft. The CertTypeExtension structure is defined
> as:
>    struct {
>       select(ClientOrServerExtension)
>           case client:
>             CertificateType certificate_types<1..2^8-1>;
>           case server:
>             CertificateType certificate_type;
>       }
>    } CertTypeExtension;
> 
> but the server is expected to send more than one certificate types (as
> seen in examples). This cannot happen with the current structure.
> 
> Also the whole certificate type negotiation seems complicated. Currently
> the certificate types are defined as:
> 
>    enum { X.509-Accept (0),
>           X.509-Offer (1),
>           RawPublicKey-Accept (2),
>           RawPublicKey-Offer (3),
>           (255)
>          } CertificateType;
> 
> So a client that accepts X.509 certificates and has a raw key will send
> (from the example in the draft)
> 
> certificate_type=(X.509-Accept(0), RawPublicKey-Offer(3)) ->
> 
>                             <-  server_hello,
>                                 certificate_type=(X.509-Offer(1),
>                                      RawPublicKey-Accept(2)),
> 
> Which can be confusing. Why sbd suggest 0,3 and the server reply with 1,2?
> 
> I think it would be much simpler to have the certificate type defined as
>    enum { X.509 (0),
>           RawPublicKey (1),
>           (255)
>          } CertificateType;
> 
> and then modify the extension as:
>    struct {
>       select(ClientOrServerExtension)
>           case client:
>             CertificateType client_certificate_types<1..2^8-1>;
>             CertificateType server_certificate_types<1..2^8-1>;
>           case server:
>             CertificateType client_certificate_type;
>             CertificateType server_certificate_type;
>       }
>    } CertTypeExtension;
> 
> Which will result in a simpler exchange, and there is no need to know
> which side is it in order to interpret the contents of the messages.
> 
> client_certificate_type=(raw(1))
> server_certificate_type=(x509(0))
> 
>                             <-  server_hello,
>                                 client_certificate_type=(raw(1))
>                                 server_certificate_type=(x.509(0))
> 
> regards,
> Nikos