Metadata Distribution Subcommittee of TAC

[John Krienke <>]

11 July 2013

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

MINUTES
----------------------

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 
CP/CPS
AI  Ask Leif about any standards that address MD and/or non-PKI signing 
practices.
AI  Document statement about key lifetime (and its cert wrapper validity 
period)


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

HISTORY
-----------------------
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).

ONLINE.

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.