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
Attachment:
signature.asc
Description: This is a digitally signed message part.
