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

Re: Validity periods can be handled more explicitly



	I think you have raised two important points and I agree that these are two 
of the dirty little secrets -- the not-carefully-thought-through elements 
that people just assume everyone agrees on.  We attacked the biggest subh 
item with SPKI from the start: the meaning of the cert itself.  But, there 
remain others.

	What does a signature mean?  Literally, it means that the keyholder applied 
his/her/its private key to the body of the signed thing.  That says nothing 
about the intention of the keyholder at the time, unless the intention is 
indicated somehow in the signed body.  The first example of this was when 
the body was a certificate -- and, as I said, we attacked that one.  We 
haven't addressed non-cert signed bodies yet.  Do we need to?

	I now speak of certificates as *empowering* a public key, when I give 
talks, and the word seems to be especially apt.  Could it be that a 
signature on a document empowers the document, somehow?

	We may have been thinking this way back when we included the hash of an 
arbitrary object as one option for the subject of a certificate.  In that 
case, the cert becomes instead an elaborated signature block -- with a 
meaning field and validity fields.  Are you suggesting that we need to make 
that the only kind of signature?

>Validity periods on certificates cause big problems. They are clearly 
>meant to modify the assertion being made, but it is not clear in what 
>way. In the X.509 world of identity certificates, people trying to use 
>them aren't clear what the validity period means. Does it limit the 
>validity of:
> a. The public key
> b. The identity
> c. The link between them
> d. Does it assert that any of the above is definitely invalid outside
>    the specified period, or just not defined?

I know there are big problems here.  I've seen some of the discussion.

To me it's clear.  The validity field limits the validity of the certificate 
itself.  When validity says "FALSE" (date expired or online test says 
FALSE), then it is as if the certificate doesn't exist.

I started to write "never existed", but that's one of the problems.  If a 
certificate goes invalid, is it retroactively invalid?  ...or does it just 
say that it it invalid at a certain time?

That leads to another problem with validity periods: the non-secure time.  
We don't have time stamping, so if a cert was valid until Aug 1, 1997, we 
don't know if the document signed by the key empowered by that cert was 
signed before the cert expired.

This confusion stems partly from the anti-matter theory of CRLs.  ...ie., 
that one can say "oops" about certificates.  Validity tests have often been 
thought of as a way to say "oops" or to prevent the use of invalid keys.  I 
believe that we can't think that way -- that once we release a certificate 
(or its revalidation or a CRL lacking it), we have committed ourselves to 
honor that cert even when what it says is wrong -- ie., even when its 
private key has been stolen.  However, this is a long discussion and I don't 
want to monopolize it.

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street  PGP 08FF BA05 599B 49D2  23C6 6FFD 36BA D342 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |

Follow-Ups: References: