On 02/24/2017 08:29 AM, Jan Cholasta wrote:
On 23.2.2017 19:06, Martin Basti wrote:

On 23.02.2017 15:09, Tomas Krizek wrote:
On 02/22/2017 01:44 PM, Fraser Tweedale wrote:
On Wed, Feb 22, 2017 at 01:41:22PM +0100, Tomas Krizek wrote:
On 02/22/2017 12:28 AM, Fraser Tweedale wrote:
On Tue, Feb 21, 2017 at 05:23:07PM +0100, Standa Laznicka wrote:
On 02/21/2017 04:24 PM, Tomas Krizek wrote:
On 02/21/2017 03:23 PM, Rob Crittenden wrote:
Standa Laznicka wrote:

Since we're trying to make FreeIPA work in FIPS we got to the point where we need to do something with MD5 fingerprints in the cert plugin. Eventually we came to a realization that it'd be best to get rid of them as a whole. These are counted by the framework and are not stored anywhere. Note that alongside with these fingerprints SHA1 fingerprints
are also counted and those are there to stay.

The question for this ML is, then - is it OK to remove these or would you rather have them replaced with SHA-256 alongside the SHA-1? MD5 is a
grandpa and I think it should go.
I based the values displayed on what certutil displayed at the time (7
years ago). I don't know that anyone uses these fingerprints. The
OpenSSL equivalent doesn't include them by default.

You may be able to deprecate fingerprints altogether.

I think it's useful to display the certificate's fingerprint. I'm in
favor of removing md5 and adding sha256 instead.

Rob, thank you for sharing the information of where the cert fingerprints are originated! `certutil` shipped with nss-3.27.0-1.3 currently displays SHA-256 and SHA1 fingerprints for certificates so I propose going that way

IMO we should remove MD5 and SHA-1, and add SHA-256. But we should
also make no API stability guarantee w.r.t. the fingerprint
attributes, i.e. to allow us to move to newer digests in future (and
remove broken/no-longer-secure ones).  We should advise that if a
customer has a hard requirement on a particular digest that they
should compute it themselves from the certificate.

What is the motivation to remove SHA-1? Are there any attacks besides
theoretical ones on SHA-1?

Do other libraries already deprecate SHA-1?

Come to think of it, I was thinking about SHA-1 signatures (which
are completely forbidden in the public PKI nowadays).  But for
fingerprints it is not so bad (for now).

Actually, there's been a practical SHA1 attack just published [1].
Computational complexity was
9,223,372,036,854,775,808 SHA1 computations, which takes about 110 years
on a single GPU.

Therefore, I'm in favor to deprecate SHA1 as well and provide only SHA256.

[1] - https://shattered.io/

I think we should wait with removal SHA1, don't remove it prematurely.
As MD5 is deprecated for very long time, SHA1 is not and we are not
using it for any cryptographic operation nor certificates. It is just
informational fingerprint.


+1, I don't favour the http://new2.fjcdn.com/gifs/Everybody_d72014_61779.gif approach.

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to