This is about adding a new signature primitive (such as the (eventual) CFRG scheme).
There are basically two issues: 1) Do we allocate new ciphersuite codepoints or not? So far each certificate algorithm in ciphersuite has corresponded to only one signature algorithm. Implications of new codepoints: - More ciphersuites (about 11). - Needs TLS 1.2+ anyway, because the ciphers are presumably AEAD mode and those need TLS 1.2+. - Keep existing semantics. Implication of reusing ECDSA codepoints. - No new ciphersuites - Needs TLS 1.2+ - Redefines existing semantics a bit. 2) What does the SignatureAndHashAlgorithm.hash mean exactly? The TLS 1.2 RFC isn't specific enough. I see two choices: a) The field sets hash (prehash) to perform before passing the hash to be signed (the description of "none" and description of Certificate Verify message hints at this interpretation). b) The field parameterizes the signature scheme in some scheme- specific way (but what would "none" mean in context of this, the scheme having no hash parameters?). All the existing schemes are compatible with interpratation a). But for proposals for CFRG scheme: All proposed schemes have a hash parameter (the only one or one of two) that is incompatible with interpretation a): 1) Only one hash that does not prehash the message. 2) Two hash functions, one prehash (can be identity) and one internal hash. Prehash can be chosen per-signature. 3) Two hash functions, one prehash (can be identity) and one internal hash. Prehash is not indicated, so one has to be careful changing it. So if interpretation a) is the correct one, one presumably has to fix the internal hash in signature scheme codepoint (E.g. to SHA-512 for signature scheme #4). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
