[Freeipa-devel] MD5 certificate fingerprints removal

[Martin Basti]

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