Protection of private keys
[Jens Jensen, 2004.10.06]

The subject this time is not the _generation_ of the keying material,
but rather the _protection_ of the private key ("Activation Data",
AD); that, and single sign-on.

We're currently saying that the user's private key must be protected
by a passphrase that is sufficiently strong -- in minreqs v 3.1,
section 4 we say "12 characters"; in my "final" (Oct 16 2002) version
of the GGF CAOPS document it says "16 characters, using upper and
lower case letters or special characters" (Subscriber obligations,
section 2.1.3).

[Of course, in practice, the private key is also protected by a Unix
file permissions (if on Unix), whereas the proxy is protected only by
file permissions.]

As a better alternative to SIPS, suppose users still keep full control
over their private keys, but can unlock it with other things than
passphrases.

Perhaps OTP, perhaps an Estonian smartcard.  My current idea
is this: a site-central server holds the passphrases (or more
likely passkey) for users at that site (but not the keys!), so
if/when I come in with my KB5 ticket, a login script can automatically
fetch the passphrases and generate my Grid proxy.  It could also
be done from a portal via some fancy php or servlets.

This latter example would go a long way towards "single sign-on" (SSO)
on the Grid (as Mike says, users may not know what SSO is, but they
know when they *don't* have it).  I use my site authentication
mechanism to unlock my private key, and in this case generate a Grid
proxy.

It is always possible to split the private key into two (or more)
equally strong parts.  We do it with the passphrase; if the passphrase
has sufficient entropy (>=128 bits) then, for all practical purposes,
the private key has been split (that's how I moved my CA's private
key backup to a separate building, by moving each part of the key
individually to the secure location).

So in summary, I think it would be useful to allow also users' private
keys to be protected by other AD than passphrases.  However, it will
again be more work for the CA because it will have to explain how end
users protect their private keys (RFC2527, section 4.6.2).  The CA
will have to convince the usual suspects (RPs and peers) that it
operates safely and to describe *all* instances of AD with a chain
*all* the way back to the user -- but at least the paranoid CA manager
will have more control over the users' AD.

Comments?

Thanks,
		--jens