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 13 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.

InCommon Operations will physically REMOVE ALL ENTITY DESCRIPTORS THAT CONTAIN A WEAK KEY from InCommon metadata on FEBRUARY 28, 2013. This includes ALL entity descriptors containing a weak key less than 2048 bits, regardless of any other keys in that entity descriptor, in either IdP or SP metadata. Here is the timeline:

  • On January 31, an email reminder of the end-of-February removal event will be sent.
  • On February 21, a final reminder via email will be sent.
  • On February 28, 2013, InCommon Operations will remove all entity descriptors in metadata (both IdPs and SPs) that contain a weak key.

There is an Appeal Process for sites unable to meet the the above deadline:

  • An organization may appeal for an extension. If the appeal is received by February 25th, and the request for appeal is approved, an extension to end-of-term (May 30th) will be granted.
  • On May 30, 2013, all entity descriptors in metadata that contain a weak key will be removed, including previously appealed exceptions.

If you have any questions at all, please contact us at admin at incommon dot org

The report data in the following frame is LIVE DATA (view a copy of the most current data 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.

Quick Summary of Weak Keys in Metadata

 

2012-08-17

2012-09-20

2012-10-10

2012-10-22

2012-11-12

2012-12-17

IdPs:

26

19

15

15

15

11

SPs:

65

53

48

40

35

25

 

 

 

report

report

report

report

An up-to-date [InCCollaborate:Report on Weak Keys in Metadata] lists those organizations with one or more weak keys in metadata. If your organization is on this list, we ask that you migrate any certificate containing a weak key 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