On Sat, Dec 17, 2016 at 01:07:52PM -0500, Scott Schmit wrote: > On Sat, Dec 17, 2016 at 06:05:49PM +0100, Nicolas Chauvet wrote: > > Maybe we need to rename FUTURE by QUITE_SOON instead, because the > > error you have pointed is about sha-1 been deprecated: > > > > According to this blog, chrome will remove support for sha-1 > > certificates on 1 January 2017 (it's an old post, so I don't know if > > it's still current). > > https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html > > > > the getfedora certificates is signed with sha-256, but the root CA has > > signed the intermediate certificate with sha-1. That the issue. > > Storing the root keys as certificates makes sense from an implementation > standpoint -- it conveniently associates the keys with the subject DNs > and other properties like key usage, but the self signature (or > otherwise) is already nonsense -- either I already trust the key (thus I > don't need to validate it) or I don't (in which case the signature can't > be trusted either). > > Thus, if the signature on the certs in the trust store matter, that's a > bug. The presence of the keys in the trust store should be all that's > required for them to be trusted -- the details of the signature > algorithm can't be irrelevant. "can't be relevant", I meant.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
