[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Open issue: key revocation


On Mon, 21 Apr 1997, Carl Ellison wrote:
> 11.	Does anyone have an application requiring key revocation?
> 	None did, in the meeting.

This is not an application per se, but key revocation becomes necessary
when a (private) key gets compromised.

I have the impression that although SPKI/SDSI defines an excellent
framework for making statements about principals/keys, there is little
attention given to key-management issues.  The draft seems a bit
contradictory in this regard.  In 2.2, it says "We do not cover ... 
key/certificate storage and acquisition" but in 3.2.1 it says "We will
have to provide for methods of announcing the compromise of such private
keys whenever this assumption [that private keys are private] proves

I think SPKI/SDSI needs to be very clear when it comes to key compromise
and revocation.  For example, I may define a group to be a set of keys,
but if one of those keys gets compromised, do I have to change my group
definition after somehow learning of the compromise?  I will if I've
defined my group as an explicit list of key values (rather than using,
say, names).  This should be made clear in the draft, as should any issue
arising from a key compromise & revocation.

Things have gotten a bit muddied with talk of issuer-as-verifier, CRL vs  
online testing and validity periods.  All of it has centered around tags,
but it's very different when you deal with the keys themselves: tag
validity is defined by a cert's issuer while key validity is defined by a
cert's subject(s).

So the issue is twofold: (1) How does one revoke a key (as opposed to a
tag)? and (2) How does that revocation propagate efficiently to everyone
who has issued a cert about the key? 

I suppose there's also a third aspect: How do all those certificate
issuers obtain a replacement key value?  Presumably, just because I've
lost my private key doesn't change the fact that I can drive a car. 


Version: 2.6.3ia
Charset: noconv


Follow-Ups: References: