Re: [TLS] TLS 1.3 certificate delegation?

[Michael D'Errico <[e-mail]>]

Johannes Merkle wrote:
>>> FWIW, there's precedent for using new TLS versions to expand the set
>>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>>> will reject those.
>> TLSv1.1 will certainly not reject those.
>> It is only rfc4492 that incorrectly alleges that those should be rejected.
> 
> I think you are wrong: Section 7.4.2 of RFC 4346 states
> 
>                               Unless otherwise specified, the signing
>       algorithm for the certificate MUST be the same as the algorithm
>       for the certificate key.
> 
> 
> Section 7.4.2 of RFC 5246 states
>                                                                   Note
>    that this implies that a certificate containing a key for one
>    signature algorithm MAY be signed using a different signature
>    algorithm (for instance, an RSA key signed with a DSA key).  This is
>    a departure from TLS 1.1, which required that the algorithms be the
>    same.

I don't believe that there was ever a requirement for a client to reject
a certificate chain based on the signature algorithms.  The requirement
is for what a server must send to the client when it has no knowledge
about the client's capabilities.  The cipher suite list sent by a client
provides a hint at its capabilities, but it was made explicit in TLS 1.2.

It would be a bad idea to send an RSA key signed with ECDSA, for example,
without knowing that the client can handle ECDSA.  That is the purpose
of the signature_algorithms extension.

If a client were to receive a certificate containing an RSA key that is
signed by ECDSA, and it happens to know how to validate ECDSA, there is
no reason to abort the connection.

Mike