The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

In January 2010, InCommon Operations announced that all certificates in metadata must have at least 2048-bit keys by the end of December 2012. While all new certificates are now required to have at least 2048-bit keys, there are still certificates in metadata with keys less than 2048 bits. These certificates must be migrated out of metadata ASAP but no later than December 2012.

Quick Summary of Weak Keys in Metadata

 

2012-08-17

2012-09-20

2012-10-10

2012-10-22

2012-11-12

IdPs:

26

19

15

15

15

SPs:

65

53

48

40

35

 

 

 

report

report

report

The report data in the following frame is LIVE DATA (view a copy of the current report in its own browser window)

Unknown macro: {iframe}

Some content

We have compiled a complete list of certificates in metadata so you can determine whether or not you have certificates that need to be replaced. This file is updated daily. If your organization has a certificate in metadata with a 1024-bit key, we ask that you migrate this weak certificate to a new certificate containing a 2048-bit key as soon as possible.

Optimal Key Size

The InCommon Technical Advisory Committee recommends that all certificates in metadata contain 2048-bit keys. Keys larger than 2048 bits are allowed but not recommended since such keys are computationally expensive (for all parties, both IdPs and SPs) but yield little increase in security.

Be aware that certificate migration may take weeks depending on how often your federation partners refresh metadata. Related to this, a new document on Certificate Migration describes how to systematically replace an old certificate with a new certificate in metadata without affecting interoperability.

Certificate Migration

Do not simply replace one certificate with another in metadata! Consult the Certificate Migration topic for recommended practices that insure continued interoperability throughout the migration process.

In the InCommon Federation, the use of long-lived, self-signed X.509 certificates in metadata is strongly recommended. A self-signed certificate containing a 2048-bit key is easily created with the OpenSSL command-line tool. Before doing so, develop a strategy for [securely handling the private key], since the security of your deployment (and that of your partners) depends on the security of the private key used to sign and/or decrypt messages.

No files shared here yet.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels