...
If you verify the digital signature on InCommon metadata (as recommended), the following implementation plan may affect your metadata refresh process. Even if you don't verify the signature (which is not recommended), note that the HTTP location of InCommon metadata is changing.
Anchor | ||||
---|---|---|---|---|
|
Drivers
- The InCommon metadata signing certificate expires on May 2, 2014.
- If we don't issue a new metadata signing certificate by May 2, 2014, an expired signing certificate will be bound to the XML signature in metadata.
- The InCommon metadata signing certificate is signed by a legacy CA whose certificate expires on March 29, 2014.
- If we don't issue a new metadata signing certificate by March 29, 2014, an expired CA certificate will be bound to the XML signature in metadata.
- The CA certificate adds nothing to the security of metadata, so its presence (expired or not) only serves to confuse consumers.
- The XML signature on InCommon metadata uses the deprecated (and soon-to-be disallowed) SHA-1 digest algorithm.
- NIST deprecated the use of SHA-1 in conjunction with digital signatures on January 1, 2011.
- NIST disallows the use of SHA-1 in conjunction with digital signatures after January 1, 2014.
- See: NIST SP 800-57 Part 1, Revision 3 (July 2012), Tables 3 and 4
- Multiple, heterogeneous services currently run on vhost
wayf.incommonfederation.org
, namely, Metadata Services and the Discovery Service. To provide better quality of service, these services need to be segregated onto their own vhosts (md.incommon.org
andds.incommon.org
, resp.). This will allow us to fine-tune each service according to its requirements.- Note: The InCommon Federated Error Handling Service is already running on
ds.incommon.org
.
- Note: The InCommon Federated Error Handling Service is already running on
- Multiple metadata aggregates will allow us to deploy changes to InCommon metadata more quickly and safely. Metadata consumers will have options depending on the requirements of their deployment.
...