[Freeipa-devel] MD5 certificate fingerprints removal

[Standa Laznicka]

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.