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/ -- Tomas Krizek
signature.asc
Description: OpenPGP digital signature
-- 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
