Re: "Last call" on draft-altman-tls-channel-bindings-05.txt

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> Quoting:
> 
>    Description: The hash of the TLS server's end entity certificate
>    [RFC5280] as it appears, octet for octet, in the server's Certificate
>    message (note that the Certificate message contains a
>    certificate_list, the first element of which is the server's end
>    entity certificate.)
> 
> I suggest replacing "server's end entity certificate" with "server's
> certificate".  As far as I understand, it is possibly to use non-EE
> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
> terminology is to say "sender's certificate" and there is no requirement
> to use a EE cert.

OK.  The thing to emphasize is that we're talking about the first cert
in the certificate_list that would be sent by the server.

(I say "would be" just to be mindful of the TLS client caching
extensions, but I don't think the I-D has to say "would" since the
certificate_list will always have been sent at one point or another.)

So how about:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function ...

> Quoting:
> 
>    agility.  The algorithm to be used, however, is derived from the
>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>    else use whatever hash function the certificate uses.  This
> 
> Please say "is signed with" instead of "uses".  Hash values may be
> present for other purposes in a certificate, but signature fields will
> typically only use one hash function.

The text you quote is security considerations text; the normative text
already says exactly what you ask for.  But OK:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.

Now, section 4.1 says "if the certificate's signature hash algorithm is
...".  But perhaps it should say "if the hash algorithm used in the
certificate's signatureAlgorithm is ...", just to be really accurate and
avoid any possible confusion (with, say, the algorithm field of
SubjectPublicKeyInfo).  Yes?

> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

Good point.

Thanks!

Nico
--