Re: [TLS] Last Call: <draft-ietf-tls-oob-pubkey-09.txt> (Out-of-Band Public Key Validation for Transport Layer Security (TLS)) to Proposed Standard

[Alexey Melnikov <[e-mail]>]

On 02/08/2013 08:23, The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG
> (tls) to consider the following document:
> - 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)'
>    <draft-ietf-tls-oob-pubkey-09.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2013-08-16. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document specifies a new certificate type and two TLS
>     extensions, one for the client and one for the server, for exchanging
>     raw public keys in Transport Layer Security (TLS) and Datagram
>     Transport Layer Security (DTLS) for use with out-of-band public key
>     validation.
Hi,
I just read the document and support its publication.

I think I found one minor issue:

Section 4.1 says:

    In order to indicate the support of out-of-band raw public keys,
    clients MUST include the 'client_certificate_type' and
    'server_certificate_type' extensions in an extended client hello
    message.  The hello extension mechanism is described in TLS 1.2
    [RFC5246].

In Section 5 (the first example):

client_hello,
    server_certificate_type=(RawPublicKey) -> // [1]

So it looks like the example doesn't comply with the MUST requirement in 
the Section 4.1 ("client_certificate_type" is missing) or the 
requirement stated in Section 4.1 is incorrect. I suspect you meant 
"'client_certificate_type' and/or 'server_certificate_type'" in Section 4.1.

Best Regards,
Alexey