Re: [TLS] Old signature schemes in CertificateRequest

[Hubert Kario <[e-mail]>]

On Monday, 3 June 2019 03:29:47 CEST Martin Thomson wrote:
>    RSASSA-PKCS1-v1_5 algorithms:  Indicates a signature algorithm using
>       RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
>       as defined in [SHS].  These values refer solely to signatures
>       which appear in certificates (see Section 4.4.2.2) and are not
>       defined for use in signed TLS handshake messages, although they
>       MAY appear in "signature_algorithms" and
>       "signature_algorithms_cert" for backward compatibility with
>       TLS 1.2.
> 
> Similar things are said about those involving SHA-1 and other "legacy"
> schemes.
> 
> My reading is that this permits the inclusion of the related signature
> schemes in CertificateRequest messages.  These can't really be used in
> CertificateVerify, so there are some interesting corner cases to consider,
> like the case where only unusable schemes are listed.

or unusable together with unknown - consider PKCS1_v1_5 with ed25519 when the 
client doesn't support ed25519

> I don't think that this rises to erratum level, but it's a bit of a problem.
>  Ideally, we'd fix this in a subsequent version by saying some more about
> CertificateRequest.  But then maybe this backward compatibility stuff will
> no longer be necessary when that time comes (he says
> optimistically/naively).

yes, ideally the RFC should be more prescriptive about handling of situation 
when all sigalgs in CR are unusable to the client, but given the RFC overall 
and Alert description explanations, I think sending handshake_failure in such 
situation is quite uncontroversial.
and of course, the client MUST NOT abort the connection upon seeing such 
legacy values in CR message
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic