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