#2960 Permit certain SHA384 FIPS ciphers to be enabled by default for RSA and ECC . . .
Closed: fixed 2 years ago Opened 3 years ago by mharmsen.

It was determined that certain SHA384 FIPS ciphers should be enabled by default for RSA:

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_256_GCM_SHA384

and the following SHA384 FIPS ciphers should be enabled by default for ECC:

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Reference:


Metadata Update from @mharmsen:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1554055
- Custom field type adjusted to None
- Custom field version adjusted to None

3 years ago

Per 10.5.x/10.6 Triage: 10.5

Metadata Update from @cfu:
- Issue assigned to cfu (was: mharmsen)

2 years ago

commit 67bb08b6948242585b015793f2ef52401533cfaf
Author: Christina Fu cfu@redhat.com
Date: Fri Aug 31 08:52:22 2018 -0700

Ticket2960 add SHA384 ciphers and cleanup profiles

This patch adds SHA384 ciphers to the cipher lists (RSA & EC)

CryptoUtil.java contains changes to clientECCiphers:
 - RSA ciphers comemented out
 - SHA384 ciphers are added but RSA ones commented out

Also added SHA384withRSA to ca.profiles.defaultSigningAlgsAllowed.

In addition, a few cleanups are done:
- all MD2, MD5 from allowed signing key algs from profiles
- server profiles:
  * removed clientAuth oid 1.3.6.1.5.5.7.3.2 from cmc server profiles
  * fixed a couple KU's (RSA vs EC) that had true/false flipped
- caCMCkraStorageCert.cfg
  * removed EKU (funny it had clientAuth)
- caCMCkraTransportCert.cfg
  * removed EKU (funny it had clientAuth)
- base/ca/shared/conf/eccServerCert.profile
  * added the missing CommonNameToSANDefault

Tested with the following:
- installation of an RSA CA and a KRA (strip down to only SHA384 ciphers)
  * performed successful agent access
  * tested key archival
- installation of an EC CA (strip down to only SHA384 ciphers)
  * performed successful agent access
  * tested an agent-signed CMC request and submitted/issued successfully
    using HttpClient

The above tests showed:
- The SHA384 ciphers work out of box
- The TLS server and client profiles changes did not break any TLS connections.
- The KRA storage and transport profile changes did not break anything.

fixes https://pagure.io/dogtagpki/issue/2960

Change-Id: I6f5cc90ba0eb4a5bfb85d86abbe2c28882cbc6ca

Metadata Update from @cfu:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.6 (was: 10.5)

2 years ago

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.13 (was: 10.6)

2 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/3078

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata