...
In
...
January
...
2010,
...
InCommon
...
Operations
...
announced
...
that
...
all
...
...
...
...
must
...
have
...
at
...
least
...
2048-bit
...
keys
...
by
...
the
...
end
...
of
...
December
...
2012.
...
In
...
anticipation
...
of
...
this
...
deadline,
...
InCommon
...
Operations
...
began
...
a
...
comprehensive
...
communications
...
campaign
...
in
...
June
...
2012.
...
The
...
goal
...
of
...
the
...
campaign
...
was
...
to
...
inform
...
Site
...
Administrators
...
of
...
the
...
security
...
risks
...
associated
...
with
...
weak
...
keys
...
in
...
metadata,
...
and
...
to
...
educate
...
them
...
how
...
to
...
mitigate
...
the
...
risk,
...
that
...
is,
...
how
...
to
...
...
...
...
...
...
...
...
...
...
.
...
To
...
make
...
a
...
long
...
story
...
short,
...
the
...
last
...
remaining
...
weak
...
key
...
was
...
removed
...
from
...
InCommon
...
metadata
...
on March 28, 2013.
...
This
...
wiki
...
page
...
and
...
its
...
child
...
page
...
(
...
...
...
...
...
...
...
)
...
are
...
the
...
historical
...
record
...
of
...
this
...
effort.
| Note | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| =
|
|
|
| ||||||
| }
The last weak key (i.e., 1024-bit key) was removed from InCommon metadata on March 28,on March 28, 2013. Since all _new _certificates are now required (by the software) to have at least 2048-bit keys, InCommon metadata will remain free of weak keys indefinitely. |
The report data in the following frame is LIVE DATA (view a copy of the most current data in its own browser window)
| Wiki Markup |
|---|
{note} *The report data in the following frame is LIVE DATA* (view a copy of the [most current data|https://wayf.incommonfederation.org/reports/certs/cert-report.txt] in its own browser window) {iframe:height=370|width=700|src=https://wayf.incommonfederation.org/reports/certs/cert-report.txt}Some content{iframe} |
We
...
have
...
compiled
...
a
...
...
...
...
...
...
...
for
...
your
...
convenience.
...
This
...
file
...
is
...
updated
...
daily.
...
Historical
...
Summary
...
of
...
Weak
...
Keys
...
in
...
Metadata
| 2012-08-17 |
|---|
...
2012-09-20 |
|---|
...
2012-10-10 |
|---|
...
2012-10-22 |
|---|
...
2012-11-12 |
|---|
...
2012-12-17 |
|---|
...
2012-12-27 |
|---|
...
2013-01-30 |
|---|
...
2013-03-28 |
|---|
...
IdPs: | 26 | 19 | 15 | 15 | 15 | 11 | 11 | 7 | 0 |
SPs: | 65 | 53 | 48 | 40 | 35 | 25 | 18 | 12 | 0 |
|
|
|
|
A Report on Weak Keys in Metadata records the history of weak keys in metadata.
| Info | ||
|---|---|---|
| ||
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.
| Warning | ||
|---|---|---|
| ||
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.
| Attachments |
|---|