Do we want to be tied to TLS signing algorithms?

[benl@…]

Russ Housley observes:

In Section 2.1.4, this protocol supports two signature algorithms. I do not think this raises any algorithm identifier concerns because the digitally-signed structure from TLS is used. By reusing this structure, you are accepting the IANA Registry rules for algorithm identifier assignment. This leads to a question: will this protocol ever need a hash algorithm identifier or a signature algorithm identifier that is not already registered? I ask because the rules are strict (because the number of identifiers is not very big)...

• TLS SignatureAlgorithm? Registry:

-- Values in the range 0-63 (decimal) inclusive are assigned via Standards Action.
-- Values in the range 64-223 (decimal) inclusive are assigned via Specification Required.
-- Values from 224-255 (decimal) inclusive are reserved for Private Use.

• TLS HashAlgorithm? Registry:

-- Values in the range 0-63 (decimal) inclusive are assigned via Standards Action.
-- Values in the range 64-223 (decimal) inclusive are assigned via Specification Required.
-- Values from 224-255 (decimal) inclusive are reserved for Private Use.

[eranm@…]

It does simplify implementation by being able to pass the DigitallySigned? structure into OpenSSL/NSS for validation of the signature.

[eranm@…]

If a hash/signature algorithm is not good enough to be used in TLS then it's probably not useful for CT. Marking as closed.