Subject: Metadata Distribution Subcommittee of TAC
- From: John Krienke <>
- To: <>
- Subject: [md-distro] Minutes : 11 July 2013
- Date: Thu, 11 Jul 2013 14:01:32 -0400
11 July 2013
Review the charter and phases of the group
Plunge into the first item: a recommendation on the fate of the CA and metadata signing key.
Send any errata if needed.
Present: John Krienke, IJ Kim, Steve Thorpe, Mark Scheible, Ian Young, Scott Cantor, Tom Scavo, OJ Redhair, Harry Nicholos
ACTION ITEMS PRODUCED BY DISCUSSION
AI Add a third deliverable in phase 1 about communication to participants
AI FOPP will need to be updated.
AI Necessary documentation around the signing key is important if not in a
AI Ask Leif about any standards that address MD and/or non-PKI signing
AI Document statement about key lifetime (and its cert wrapper validity
Context of MD-Distro as one of the 7 priorities outlined by the Technical Advisory Committee (TAC) in the fall of 2012 and as confirmed by community discussion at the Internet2 Fall Member Meeting. Those 7 were: Assurance, Interfederation, MD distribution, Federated User Experience, MD administration, Supporting Net+ applications, and Mobile/Non-browser federated apps.
InCommon began in 2004 with a full blown CA issuing InCommon server certs to all participant entities. We realized an InCommon-centric CA trust model would not advance international interfederation, and in 2009, we moved as a participant community to self-signed certificates in metadata (although a few InCommon-issued certificates long-expired still exist in metadata today). The current MD signing key is rooted in this CA, whose root cert is set to expire 29 March 2014.
DISCUSSION OF SIGNING KEY ROOTED IN VESTIGIAL INCOMMON CA
We can't be 100% certain that no one is relying on the CA. However, there is no practical reason or deployment we know of to make us think that's true.
This current deadline raises an opportunity to be more explicit in our documentation on ways we expect participants to do MD validation. Good opportunity to communicate that we're either renewing the cert or changing our strategy. Most of our recommendations are documented on the MD consumption pages: https://spaces.internet2.edu/x/JwQjAQ
Phase 1: End of August seems a reasonable deadline for recommendation
AI add a recommendation on what this communication looks like to send to participants. What are we going to tell people and what actions are required (of InCommon, of Participants).
Primary consideration for a CA in two use cases: Offline, and Online. Discussion below revealed no known compelling use case for a CA with offline signing.
Main people doing PKI are Swiss (online).
UK has a self-signed root Cert. Every couple of years a set of entities who /are/ doing validation of the expiry date on the certificate ("eduserv" software, with 150 entities 10% of population). PKI gives people the necessity of not paying attention when the signing key rolls over. Can revoke the metadata signing key without much reconfiguration. BUT, you need to do a reconfiguration when the Root Cert rolls over. So, it's the /same/ issue for a long-lived signing key as for a long-lived root cert. Consensus discussion, advocating that the subordinate cert (aka the signing cert) have a long life.
SimpleSAMLphp (SS) works by storing the fingerprint of the /cert/. A cert renew or rekey breaks the SS config. Shib only looks at the key, not the cert wrapper.
Possible for a scenario where something won't accept a self-signed signing key. Most software with a PKIX model -- root of a trust path does not have to have a CA. If you can build a path from the cert being evaluated and the cert to be trusted is valid, that's OK.
Argument: We want to maximize compatibility, but still reasons to treat that as an additional feature and still make sure primary signing key is long-lived (e.g., for SS). We could create a PKIX like after-the-fact model by having the signing key sign signed by a CA key later.
eduGain: Uses a self-signed cert to sign their MD. Online signing. Don't know about their security implementation (HSM, etc).
Do you still need a PKIX even if you go online? Revocation practice around an online key (a lot of work with uncertain benefit). If we got rid of the CA, we would not need to rekey the signing cert (key lifetime is separate issue).
AI FOPP would need to be updated.
AI Necessary documentation around the signing key is important, but it's NOT a CA CP/CPS. Someone in the world might have a template format around documentation for signing keys. AI ask Leif. Metadata practice statement.
How should we handle the key, how long is long, etc. 10 years is how long we've been using the current key. AI this is the question. Two different points: certificate validity is different than key lifetime. We need to define and impose these ourselves. Opinion to NOT use x.509 to express that.
Answer for key lifetime of our current md signing key. Can we come up with any statement about lifetime without a corresponding statement of what we're trying to prevent? 2048 RSA is a long way from a brute force attack. No -- known -- rational reason to put any end date on a key lifetime (but practical reason prior to 2038).
Next discussion on July 18th...
A more thorough review of Online signing and whether a CA is needed to meet future requirements.
- [md-distro] Minutes : 11 July 2013, John Krienke, 07/11/2013
Archive powered by MHonArc 2.6.16.