Bug 2102751

Summary:	mark SHA-1 verification in FIPS as non-approved, not just block with config
Product:	Red Hat Enterprise Linux 9	Reporter:	Alexander Sosedkin <asosedki>
Component:	gnutls	Assignee:	Daiki Ueno <dueno>
Status:	VERIFIED ---	QA Contact:	Alexander Sosedkin <asosedki>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	9.1	CC:	awestbro, ssorce
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	gnutls-3.7.6-23.el9	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Sosedkin 2022-06-30 14:40:52 UTC

Doesn't look like we want to certify SHA-1 verification at all, even though it's allowed for legacy usage.
SHA-1 verification is blocked with config in FIPS, but for certification we should either hard-block or indicator-disapprove.
I propose doing the latter downstream. Impact should be minimal if we block it by default anyway.

Upstream test that checks for verification being approved:
https://gitlab.com/gnutls/gnutls/-/blob/ebfe675f15bfb52d61451e96d0f73d792a2b9a9b/tests/fips-test.c#L457

Comment 1 Daiki Ueno 2022-07-01 05:20:43 UTC

(In reply to Alexander Sosedkin from comment #0)
> Doesn't look like we want to certify SHA-1 verification at all, even though
> it's allowed for legacy usage.
> SHA-1 verification is blocked with config in FIPS, but for certification we
> should either hard-block or indicator-disapprove.
> I propose doing the latter downstream. Impact should be minimal if we block
> it by default anyway.

DSA verification is also allowed for legacy use but we mark them non-approved in upstream, so I guess we could do the same for SHA-1 signature verification.