On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett <davemgarr...@gmail.com> wrote:
> On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote: > > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and > > Ed448ph. And keys MUST NOT be mixed between those. > > > > I propose the following: > > - EdDSA uses one SignatureAlgorithm value (5?[1]). > > - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and > > another for Ed448/Ed448ph > > - If there is ever EdDSA instantiation with Edwards448 curve (the same > > one Ed448 uses) with another KDF, it gets a new curve distinct from > > Ed448/Ed448ph. > > - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or > > value matching the prehash (but the prehash is always done once[2]). > > [TBD: resolve this] > > I've been thinking about the issue of how to handle > SignatureAndHashAlgorithm values better. I think this time, I'd like to > propose going the opposite way we'd normally want to move: let's consider > enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of > having independent values. We're moving to signature algorithms that don't > have arbitrary hashes, so the current system isn't really ideal anymore. > > Current draft: > https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1 > (text) > https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88 (full > registry) > ---------------------------------------- > enum { > none(0), > md5_RESERVED(1), > sha1(2), > sha224_RESERVED(3), > sha256(4), sha384(5), sha512(6), > (255) > } HashAlgorithm; > > enum { > anonymous_RESERVED(0), > rsa(1), > dsa(2), > ecdsa(3), > rsapss(4), > (255) > } SignatureAlgorithm; > > struct { > HashAlgorithm hash; > SignatureAlgorithm signature; > } SignatureAndHashAlgorithm; > ---------------------------------------- > > Proposed replacement backwards-compatible registry: > ---------------------------------------- > struct { > anonymous_RESERVED(0x0000), > rsa_nohash(0x0001), > dsa_nohash(0x0002), > ecdsa_nohash(0x0003), > rsapss_nohash(0x0004), > md5_RESERVED (0x0100..0x01FF), > rsa_sha1(0x0201), > dsa_sha1(0x0202), > ecdsa_sha1(0x0203), > rsapss_sha1(0x0204), > sha224_RESERVED (0x0300..0x03FF), > rsa_sha256(0x0401), > dsa_sha256(0x0402), > ecdsa_sha256(0x0403), > rsapss_sha256(0x0404), > rsa_sha384(0x0501), > dsa_sha384(0x0502), > ecdsa_sha384(0x0503), > rsapss_sha384(0x0504), > rsa_sha512(0x0601), > dsa_sha512(0x0602), > ecdsa_sha512(0x0603), > rsapss_sha512(0x0604), > (0xFFFF) > } SignatureAndHashAlgorithm; > ---------------------------------------- > > New values could be assigned specific combinations as needed. This would > also let hashes & signatures be deprecated independently easily, e.g. allow > rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from > the start). I am not in favor of this change. Because we can already indicate combinations, this doesn't seem to add significant new value. If we need to indicate "signature algorithm without a hash" then a "none" hash is the simplest solution. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
