[Go to /]
Structures
Membership
Contact us

IGTF
APGridPMA
TAGPMA
REFEDS
SCI
WISE

Documents
Charter
Guidelines
One Statement Policies

CAOPS-WG
Wiki

Technical Info
CA Distribution download
Subject Locator
Find your local CA
About your certificate

Newsletter issues
Subscribe
Service notices

Tools download and fetch-crl
Technical documentation
IGTF OID Registry
SHA-2 timeline

Meetings
CERN, Geneva, CH, Feb 5-7, 2025
Amsterdam, NL, Sept 23-24, 2024

Overview
Agendas
Intranet and Reviews (closed)

IGTF time line statement on SHA-2 Secure Digest Mechanisms

Having consulted the major relying parties, the authority members, and the HASHRAT expert group, and based on the discussions at the APGridPMA, TAGPMA, and EUGridPMA, the following SHA-2 time line has now been endorsed by the IGTF.

before December 2013
  • CA certificates in the IGTF distribution and CRLs at official distribution points should use SHA-1
  • CAs should issue SHA-1 end entity certificates by default
  • CAs may issue SHA-2 (SHA-256 or SHA-384(512)) end entity certificates on request. CAs may publish SHA-2 (SHA-256 or SHA-384(512)) CRLs at alternate distribution point URLs
1 December 2013
  • CAs should begin to phase out issuance of SHA-1 end entity certificates
  • CAs should issue SHA-2 (SHA-256 or SHA-384(512)) end entity certificates by default
1 April 2014
  • New CA certificates should use SHA-2 (SHA-256 or SHA-384(512))
  • Existing intermediate CA certificates are encouraged to re-issue using SHA-2 (SHA-256 or SHA-384(512))
  • Existing root CA certificates may continue to use SHA-1
1 October 2014
  • CAs may begin to publish SHA-2 (SHA-256 or SHA-384(512)) CRLs at their official distribution points.
1 February 2015 and thereafter
  • All issued SHA-1 end entity certificates should be expired or revoked.
  • Existing intermediate CA certificates should be re-issued using SHA-2 (SHA-256 or SHA-384(512))
    Note that unless this is done, major browsers will stop accepting these intermediates by 1 January 2017

If SHA-1 is broken, certificates based on SHA-1 must be revoked within the IGTF RAT determined time line, which may be within one working day. (pending IGTF AHM)

In case of new SHA-1 vulnerabilities, the above schedule may be revised. Until such a case is demonstrated, there might be exceptional cases where a CA might issue SHA-1 based certs with appropriate warnings and instructions to the subscriber.

SHA-224 is not to be used as per the HASHRAT document. Note that SHA-384 does work, though (and in some or many cases is preferred over SHA-512 for compatibility reasons as per https://bugzilla.mozilla.org/show_bug.cgi?id=1129083.

Comments to David Groep. This site is hosted at Nikhef, subject to the privacy policy.