On 24.02.2017 08:46, Tomas Krizek wrote:
On 02/24/2017 08:34 AM, Standa Laznicka wrote:
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:
Hello,
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.
rob
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
too.
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.
Cheers,
Fraser
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).
Thanks,
Fraser
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
+1, I don't favour the
http://new2.fjcdn.com/gifs/Everybody_d72014_61779.gif approach.
People will most likely be using the software even years after its
upstream release, so I think its best to address these issues sooner
rather than later.
SHA256 fingerprints should be added even if we decide to keep SHA1 for now.
+1 for adding SHA256
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
