Ilari Liusvaara <ilari.liusva...@elisanet.fi> writes: > This is about adding a new signature primitive (such as the > (eventual) CFRG scheme).
I believe these aspects were already discussed in the EdDSA threads. It would be useful to establish consensus around these topics. > 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. The feedback I got on draft-josefsson-tls-eddsa from several people was to reuse the ECDSA codepoints instead of defining new ciphersuites. I am currently (mildly) in favor of that, as it appears to imply less work for everyone. I have since published draft-josefsson-tls-eddsa2 that adopts that approach. I decided to fork the draft so both are available and can be evaluated on its own. They are available here: https://tools.ietf.org/html/draft-josefsson-tls-eddsa https://tools.ietf.org/html/draft-josefsson-tls-eddsa2 > 2) What does the SignatureAndHashAlgorithm.hash mean exactly? The > TLS 1.2 RFC isn't specific enough. I believe the document introducing a new signature primitive must be clear about this. I don't believe TLS 1.2 mandates any particular interpretation here, so it is up to the new primitive to define semantics. I believe the choice is not particular interesting, as long as the specification is clear about what is intended. For example, draft-josefsson-tls-eddsa uses "none", and draft-josefsson-tls-eddsa2 uses "sha512", and both are in their own way a bit redundant. > 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). I don't think we can come any closer to my discussion above until we know what the CFRG outcome is. /Simon
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
