[Freeipa-devel] MD5 certificate fingerprints removal

[Jan Cholasta]

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

-- 
Jan Cholasta