On Oct 11, 2015, at 8:53 AM, Dave Garrett <davemgarr...@gmail.com> wrote:
> From a perspective to get it to work with the bare minimum needed, it's > excessive. From a perspective of killing SHA-1 wherever viable, it is not. I don’t think killing SHA-1 wherever viable should be a goal of this document. A certificate is a credential. It can be used in multiple protocols, standard and proprietary. Whether the certificate is trusted or not is up to the relying party regardless of what protocols that relying party uses. It is not for the TLS spec to dictate what properties a certificate should have, except when those properties make a difference for the protocol. So if we’re removing DSA from the spec, and have not yet standardized EdDSA signatures, it makes sense to require that the public key (not the signature!) in the certificate be either RSA or ECDSA. I don’t think it’s reasonable to require stuff that doesn’t enter the protocol. > Any continued legitimate allowance of a deprecated hash perpetuates other > possible continued allowances, even if the one in question is viable under > some specific circumstance. > > The goal I'm aiming for is SHA-1 being restricted to TLS 1.2 And assuming that TLS 1.3 has better security than TLS 1.2, how does this goal help security on the Internet? We are not in charge of the Internet. We are only engineering some protocols that we hope the implementers will find useful. The industry *is* moving away from signing certificates with SHA-1, but that decision is being made elsewhere. Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
