On Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote:
> So long as SHA-1 self-signatures are still tolerated in root or
> self-signed end-entity certificates, I have no objection to TLS
> 1.3 specifying that a certificate signed with SHA-1 is not trusted
> even when issued by a trusted issuer.
> 
> However, we *must* be careful about what obligations we impose on
> a client or server that encounters a certificate chain in which
> some certificate which is not self-signed uses a SHA-1 signature.
> It would be a big mistake to mandate fatal or even warning alerts
> or closing the connection.  Rather, the required outcome is that
> the chain is simply not trusted.  
> 
> Whether *that* in turn leads to a connection termination depends
> on whether verification is required.  Opportunistic clients, or
> servers that solicit optional client certificates need to be able
> to continue despite the untrusted chain, and do what they do in
> the absence of a peer certificate or when the peer certificate has
> accceptable signatures, and and yet is still untrusted (or peername
> does not match, ...).
> 
> So if the draft language for 1.3 essentially only prohibits *trusting*
> SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's
> chain, I think that should be fine.
> 
> I don't want to see client's or servers hanging up just because a
> peer presents a SHA-1 chain that would have been simply ignored
> had it been SHA2-256 instead.

Yes, to all points above. I feel like self-signed certs should have to use 
SHA-256 too, but mandating that doesn't get us that much.

The current PR is a bit too general; will need revision to handle all cases. 
I'll of course change it to accommodate concerns that come up in discussion 
here. Note that opportunistic encryption is weird and getting the whole 
document to be perfect for it might not be entirely doable, as OE needs to 
tolerate more fuzziness than the main spec should allow.


Dave

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to