Handling signature_algorithm extension on TLS1.3 server

[Hubert Kario]

On Friday, 7 June 2019 14:42:26 CEST Raja Ashok wrote:
> > This was an area of some ambiguity in the TLSv1.2 spec where only
> > signature_algorithms exists. I believe it was common practice for
> > implementations to not check the signatures in certificates for
> > conformance with
> > this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems
> > to be
> > more explicit about this. I would expect our TLSv1.2 implementation to
> > continue
> > to operate as it did before so this additional checking of signatures in
> > certificates where only the signature_algorithms extensions is present
> > should
> > only apply to TLSv1.3.
> > 
> > I don't see any code to do this in has_usable_cert so this looks like a
> > potential bug. Although possibly it was left out on purpose.
> 
> Yes. Currently this check is missing for both TLSv1.2 and TLSv1.3. I feel
> we may need to add for both TLSv1.2 and TLSv1.3, because TLSv1.2 RFC 5246
> also mandates to do this check.
> 
>    If the client provided a "signature_algorithms" extension, then all
>    certificates provided by the server MUST be signed by a
>    hash/signature algorithm pair that appears in that extension.


OTOH, the practice in TLS 1.2, and behaviour codified in TLS 1.3 RFC, is that 
if you have just one chain, give it to client and let it sort out if it likes 
it or not

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/40e787ab/attachment.sig>