igtf and sha 2 n.
Skip this Video
Loading SlideShow in 5 Seconds..
IGTF and SHA-2 PowerPoint Presentation
Download Presentation
IGTF and SHA-2

IGTF and SHA-2

76 Vues Download Presentation
Télécharger la présentation

IGTF and SHA-2

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. IGTF and SHA-2 David Kelsey TAGPMA meeting, SDSC Feb 2012

  2. WLCG status • Firstly – see slides from Maarten Litmaath about WLCG situation. SHA-2 and RFC proxies SHA-2, TAGPMA

  3. Conclusion of discussion at EUGridPMA meeting Jan 2012 • migrating to SHA2 appears to be non-trivial, since it is convoluted with a move to RFC3820 style proxy certs • There is still a bit of software out there that does not support RFC3820 proxies, and using libraries that support SHA-2 would necessitate the exclusive use of RFC proxies • So there is a deadlock here • The presentation by DaveK (from Maarten Litmaath) explains the dependencies and some wLCG considerations on the time line SHA-2, TAGPMA

  4. Conclusions (2) • We understand the complications, but at the same time the risk of using SHA-1 is increasing as more cryptanalysis is done • Basically, it would not be beneficial to subscribers or RPs to start using SHA-2 now, knowing that many things will break, and a new risk analysis is needed, taking the deployment risks into account • But at the same time the RAT and IGTF must develop a "Plan-B" in case SHA-1 is suddenly broken and we need to move to SHA-2 anyway, regardless of other consequences SHA-2, TAGPMA

  5. EUGridPMA proposal on SHA-2 With regards to the introduction of SHA-2 the PMA now proposes to the IGTF the following: •  the RAT does a risk assessment of staying with SHA-1, in light of current cryptanalytic developments and the deployment issues identified • if SHA-1 is broken, the RAT makes an immediate assessment based on the integrity of the subscriber certs, and will act regardless of RP deployment consequences • we will NOT repeat NOT recommend CAs to move to SHA-2 for production use until the risk assessment completes • noting that this provision ends in January 2013 SHA-2, TAGPMA

  6. Proposal (2) • individual CAs MAY start issuing SHA-2 based certs on their own accord anyway (e.g. for testing, or to satisfy other needs) • the date by which SHA-2 production certs may be issued will be NO LATER than January 2013 • and it is likely we will RECOMMEND CAs to move then, since it will take another 395 days to get rid of SHA-1 in a reasonable way • additional digest algorithms, in particular the successor to SHA-2 which is chosen this year, may ALSO be used in production certsin January 2013 • but will NOT be introduced before SHA-2 is recommended for general use SHA-2, TAGPMA

  7. Further notes • Note that SHA-2 is a family, so all of SHA256, SHA384 or SHA512 may be encountered in production certs following this date!  • The NIST competition for a new hash algorithm (the successor of the SHA-2 family) is completing in half a year. • The new hash family (let's call it "SHA-3") will be available in implementations by the end of this year. • RPs may expect the use of SHA-3 based certs early 2013, although not before SHA-2 is released for general use • We urge software developers to be flexible in the use of cryptography, rely on upgradable (dynamic) libraries and not tie to a specific hash, key algorithm or key size SHA-2, TAGPMA

  8. One final note • All CAs are kindly asked to stop using emailAddress(or Email, or "E") attributes. • Not only in subject names, but also in their issuer name. There are three CAs (IUCC, IHEP, APAC) that still have those • There are no such CAs in TAGPMA(?) SHA-2, TAGPMA