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.

-- 
Tomas Krizek


Attachment: 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

Reply via email to