I had a quick chat with the iANA folks about the HashAlgorithm and
SignatureAlgorithm, which we are effectively closing by marking all
unregistered bits as either reserved or depcreated. IANA suggested another way
which is to just close the registry, An example for the registry follows:
TLS HashAlgorithm Registry
Registration Procedure(s)
Closed see [this-to-be-rfc]
Reference
[RFC5246][this-to-be-rfc]
We’d make the following changes to the draft:
OLD:
[SHALL update/has updated] the TLS HashAlgorithm Registry to list
values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
to list values 4-223 as "Reserved”.
NEW:
[SHALL close/has closed] the TLS HashAlgorithm Registry and
the TLS SignatureAlgorithm registries for new assignments.
I personally think this is cleaner that reserving the values. But, it does
mean that this registries are closed for assignments.
spt
> On Mar 16, 2018, at 14:01, Sean Turner <[email protected]> wrote:
>
> During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted something
> about the HashAlgorithm and that made me go look at what was said in
> draft-ietf-tls-iana-registry-updates. Turns out that 4492bis assigned some
> values draft-ietf-tls-iana-registry-updates was marking as reserved. I have
> fixed that up in:
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65
>
> One further point brought out in discussions with Adam was that if we’re
> really closing the HashAlgorithm and SignatureAlgorithms registry we need to
> also mark 224-255 as deprecated. Currently these are marked as Reserved for
> Private Use. So the question is should we mark 224-255 as deprecated in
> these two registries?
>
> spt
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
