Time marches on, and does not (and cannot) act on its own. Only things which exist in time can act, and time is the process by which cause and effect are separated.
Since nobody can hold Time to any form of standard, except that it is agreed as a matter of policy to describe points in time in a universally coordinated sense (made possible by the fact that Time does not care who you are, it simply marches on at its own pace), and since Time is essentially operating (perceptually) as a motion left in place by intertia... it cannot be viewed as an act taken "by time passing". Action at birth, if it's the last action made, is still action; the idea is that the action of binding the identity, provably committed to by the action of signing the certificate, is an action -- the CA must choose to make the action. Consequently, inaction on the part of the CA during the term of the certificate's validity is also a choice. The revocation of a certificate is another action, and the derevocation of a certificate can be yet another action. Thus, the CA is the only one who takes actions related to its commitment to the binding. (Others may choose to disbelieve a given binding, either via not accepting the CA's statements or by specifically distrusting a specific statement; the latter can be done via a private OCSP responder among other things.) In any case, I don't buy your statement "action taken by time passing". And "the time in the universe" is a policy, nothing more. On a related subject, what precisely can be gleaned from RFC3280 (and RFC5280)'s statements about what actions a CA under PKIX commits to performing, over what period of time? -Kyle H On Mon, Jan 12, 2009 at 2:16 PM, Paul Hoffman <phoff...@proper.com> wrote: > At 1:42 PM -0800 1/12/09, Kyle Hamilton wrote: >>Technically, 'expiration' is also an action taken by the CA. > > No, it is an action taken by time passing. When the time in the univers is > the same as the time listed as "notAfter" in the cert, the cert expires. > That's it. > >>It's >>basically saying, "I attest to the validity of this binding until this >>date, *unless something extraordinary happens in the meantime*." > > No, that's *way* too strong. The meaning of the notAfter date is quite > simple: "the date on which the certificate validity period ends". (See the > subject of this thread....). A revoked certificate does not expire until > after the notAfter. > >>They really do have the same meaning -- that the CA is not willing to >>attest to the identity binding. > > No, they really don't have the same meaning. Revocation can happen even if > the CA is willing to attest to the binding but knows that doing so is silly, > such as if the CA knows that the public key has been destroyed. Similarly, a > CA might still attest to the binding between the public key and the identity > in a different certificate. > >>After expiration, the CA doesn't give >>one whit about the bound key -- and the entity which owned the >>privatekey in question could hand that key over to someone else, and >>the CA doesn't need to do anything at all because it has already >>acted. > > Quite right. > >>Remember, *everything* in the certificate is an action of the CA. It >>is the final actor in the creation of the certificate, and it is the >>final actor in the revocation of the certificate. > > An action at birth is quite different than an action at revocation. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
