I support the goal of this document, i.e. to publish the text in the
IANA repository as an RFC.
There are differences between the text in the current IANA repository
and the document. These differences are not spelled out in the document
for the 'tls-server-end-point' channel binding. The document says:
Note that the only material changes from the original registration
should be: the "owner" (now the IESG), the contacts, the published
specfication, and a note indicating that the published specification
should be consulted for applicability advice.
That is not correct, compare the content registered with IANA
The hash of the TLS server's end entity certificate 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.) The hash function to be
selected is as follows: if the certificate's signature hash algorithm
is either MD5 or SHA-1, then use SHA-256, otherwise use the
certificate's signature hash algorithm. The reason for using a hash
of the certificate is that some implementations need to track the
channel binding of a TLS session in kernel-mode memory, which is often
at a premium.
with what the document says:
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 is to be selected as follows:
o if the certificate's signatureAlgorithm uses a single hash
function, and that hash function is either MD5 [RFC1321] or SHA-1
[RFC3174] then use SHA-256 [FIPS-180-2];
o if the certificate's signatureAlgorithm uses a single hash
function and that hash function neither MD5 nor SHA-1, then use
the hash function associated with the certificate's
signatureAlgorithm;
o if the certificate's signatureAlgorithm uses no hash functions or
multiple hash functions, then this channel binding type's channel
bindings are undefined at this time (updates to is channel binding
type may occur to address this issue if it ever arises).
The reason for using a hash of the certificate is that some
implementations need to track the channel binding of a TLS session in
kernel-mode memory, which is often at a premium.
I suggest that the first paragraph quoted above from section 4 is
modified like this:
OLD:
Note that the only material changes from the original registration
should be: the "owner" (now the IESG), the contacts, the published
specfication, and a note indicating that the published specification
should be consulted for applicability advice.
NEW:
Note that the only material changes from the original registration
should be: the "owner" (now the IESG), the contacts, the published
specfication, and a clarification to the description related to
certificate's that do not use hash functions or use multiple hash
functions. We also added a note indicating that this specification
contains applicability advice, and we moved security considerations
notes to the security considerations section of this document.
The last sentence is copied from section 3 for consistency.
Also missing is in section 3 and section 5 is a note that references
were added to the text. I suggest:
OLD:
...security considerations section of this document. All other
fields of the registration are copied here for the convenience of
readers.
NEW:
...security considerations section of this document. References were
added to the description. All other fields of the registration are
copied here for the convenience of readers.
/Simon
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf