On 22/10/15 00:52, Dave Garrett wrote:
I'm in favor of this change as well. It annoys Viktor, as it changes the
fallback in a way that isn't ideal for some cases that trust the cert directly
or with OE,
IINM this also changes the fallback for servers that choose to include a
PKIX trust anchor certificate in the Server Certificate message.
Lots of publicly trusted root certificates have sha1WithRSAEncryption
signatures. TLS clients typically don't verify these SHA-1 signatures,
so there's no rush to remove them from trust anchor stores.
but I think it's better than the alternative.
Why would it make sense to prohibit the sending of PKIX trust anchor
certificates that have sha1WithRSAEncryption signatures?
Dave
On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote:
I think this is the right answer and parallels what we are doing with PSS.
-Ekr
On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <martin.thom...@gmail.com>
wrote:
The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.
That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.
I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):
https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
