[Freeipa-devel] MD5 certificate fingerprints removal

Martin Basti mbasti at redhat.com
Thu Feb 23 18:06:10 UTC 2017



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20170223/a1d41e92/attachment.htm>


More information about the Freeipa-devel mailing list