[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Validity periods can be handled more explicitly
-----BEGIN PGP SIGNED MESSAGE-----
Bob,
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
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBNFoL0BN3Wx8QwqUtAQGK4gP+NHpng9Au2hG8CGdqy1kWbanMXAaxtc7f
OYolUic2I4HS5nZ1bxAF+Mto4coEsD1PcbKecaUoT1mj6csXwQGr/f84vGEL3To3
d3UpFHo63ilZxdmsAI8Z/apKEsvNvmNgyOR9SKK8uJxYIugcC41rLd07GOZGZ2ni
bTyIfve/yIw=
=TNtU
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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: