On Thu, Dec 01, 2016 at 04:36:17AM +0000, Peter Gutmann wrote:
> Viktor Dukhovni <ietf-d...@dukhovni.org> writes:
> >So I'd like to see the text in the first paragraph changed to a SHOULD or
> >worst-case a qualified "MUST whenever possible".
> Why is that whole thing even there in the first place? From the previous
> discussions where this came up, the pretty much universal consensus was that
> people were ignoring the requirement because it served no obvious purpose
> but broke interoperability. Unless you're a server operator that chooses to
> buy a whole bunch of $995 certs, one per algorithm, from a CA that allows
> you to choose which algorithm gets used for signing, the whole thing is
> completely inapplicable. You send whatever cert chain the CA gave you to
> the client, and it's up to them to decide whether they want to accept or
> reject. What would be lost by simply removing that entire block of text,
> since it's being ignored by implementers anyway? The solution is to remove
> it, not to fiddle with it until it becomes a no-op that matches what
> everyone is doing anyway.
Using algorithms that are supported is kinda important for interop,
since if you send a non-(super-)TA certificate using algorithm the
client doesn't know, it is going to have trouble validating the
If you are referring to mixing RSA/ECDSA certs in one certificate
chain, that already works fine in TLS-1.2-as-of-spec (unless client
does something crazy). TLS 1.3 removes the options for clients to
be crazy here.
 That's related to requirment of matching EE (not any CA) certificate
type and ciphersuite, causing client to be able to trip all sorts of bugs
and edge cases in ciphersuite selection.
TLS mailing list