4

Here is the context. Suppose you have a corporate PKI with :

  • AC_Root (offline in safe store - SHA1 signature)
  • SubRootA and SubrootB (offline in safe store - SHA1 signature)
  • SubSubRootC, SubSubRootD, SubSubRootE... (online in HSM - SHA1 signature)
  • End entities certificates (servers, users smart card, auto enrollment, Active directory)

What are the impacts due to SHA1 deprecation ? I know the root certificate is not concerned, because self-signature is never verified (only presence in truststore), but what about the Subroot certificates ?

Editors like Google or Microsoft announced that browsers will print warnings and even fail when SHA1 will be used, and quite soon (2015/2016).

  • Is this a hot issue for mostly security reasons or for the user experience (warnings in browser, OS refusing SHA1 certificates) ?

  • Is it needed to organise a new key ceremony for creation of a new "SHA256" chain ? Even for offline chain (root and subroots) ? Re-issuing new end entities certificates with SHA256 ? Introducing a sliding period for key renewal ?

guntbert
  • 1,825
  • 2
  • 18
  • 21
crypto-learner
  • 697
  • 1
  • 7
  • 17

3 Answers3

4

Is this a hot issue for mostly security reasons [...]

Not yet. There is no practical published attack yet. But it's in the post. The gradual transition now is better than the transition from the earlier MD5 hashing algorithm to SHA1. Back then there was no explicit deprecation strategy AFAIK and there actually were evil attacks that used MD5-collisions. (Flame) We shouldn't wait until the same thing happens with SHA1.

Is it needed to organise a new key ceremony for creation of a new "SHA256" chain ? Even for offline chain (root and subroots) ? Re-issuing new end entities certificats with SHA256 ?

Yes. Offline or not doesn't matter. The cert chain is only as strong as the weakest link. (Excluding the root, whose signature does not matter.) And also: A CA cert is always a juicier target for an attack than an end entity certificate.

Introducing a sliding period for key renewal ?

Yes. Don't issue anything with SHA1 past the mentioned cut-off dates. If you do issued SHA1 up to the cut off date do only with written justification and manager sign-off.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • 1
    Thanks for your answer. But suppose I got several end entity certificates which expires in 2017 and SHA-1 is deprecated by most editors in 2016, how to deal with that ? Massive revocation ? – crypto-learner Nov 30 '14 at 18:54
  • You need to get the long-life SHA1 end entities certs out of circulation. This means getting them to send your (new SHA2) issuing CA another signing request and then issuing a new SHA2-signed certificate for each and every one of them. After you verify that the new SHA2-certificate has been installed and is working correctly, you can revoke the old SHA1-certificate. This will make it harder to bring it back online accidentally. (For example as part of a data restore operation or something.) – StackzOfZtuff Nov 30 '14 at 21:17
  • Also: Here's a blog by TLS guru Ivan Ristic: "SHA1 Deprecation: What You Need to Know" https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know – StackzOfZtuff Dec 01 '14 at 15:21
1

Is it a must-act-immediately-because-attacks-are-feasible-now? No. That said, when working with PKI, you must have a long vision, so start planning now.

It is estimated that by the end of 2017, precomputed hash-collisions to create imposter certificates (and hence imposter CA certificates) may drop below 100,000$ in computation, using cloud computing resources. As I am sure you know, replacing all of those certificates and establishing trust in your new CAs is non-trivial.

You will want to at least replace your offline intermediate and online issuing CAs, as well as replacing all of the leaf certificates.

If you stand up new CA infrastructure now, and if the certificates have a two year lifecycle, and if all of your applications (both server-side applications presenting certificates and clients consuming/validating certificates) can cope with SHA-2, and you keep your existing root (so you don't have to touch trust-anchors), then if you start immediately, you can simply replace the certs as part of standard renewal.

DTK
  • 1,190
  • 7
  • 8
1

I guess from reading old white papers out there, that only the self signed root CA Certificate is not affected by the SHA-1 deprecation plan and can still use SHA-1, as clients have other means to check for integrity of root certificates. All other certs should be replaced. Here is full description: http://ammarhasayen.com/2015/02/02/pki-certificate-services-sha-1-deprecation/

ammar
  • 11
  • 1