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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

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.

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.

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.

Nits:

   note (that is, the first such note in the descritption is a new
                                                   ^
/Simon