[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Validity periods can be handled more explicitly
>One thing I don't understand in the explanation of X.509 validity periods.
>If the certificate only asserts that the binding(s) were valid at the
>moment the cert was signed, what does a certificate revocation mean?
>
>Is it (A) that the bindings are no longer believed to have been valid at
>the moment the cert was signed, or is it (B) that the bindings actually
>were valid beyond that moment, but they're not valid anymore now that
>the revocation has occurred? (Or (C) something else?)
>
>Thanks,
>Hal Finney
Nicely phrased question, Hal, and one that is worth some further discussion
with my legal colleagues, which I shall do. The simple one-line answer is
probably (B), or "it depends," for it depends on the reason why the
certificate was suspended, together with some question as to whether the
signature and the certificate were issued by a licensed CA (in those states
that support such a concept) and/or was entitled to a rebutable presumption
of validity. I will also say that in my opinion the legal analysis of
certificate revocation is not yet very mature, so you should probably take
the following with a grain or two of salt.
The PKIX documents defines the following CRLReason codes:
0 -- unspecified
1 -- keyCompromise
2 -- cACompromise
3 -- affiliationChanged
4 -- superseded
5 -- cessationOfOperation
6 -- certificateHold
8 -- removeFromCRL
(In addition to these states, there has been some discussion of a Pending,
or not yet validated state which would be very similar to a certificateHold.
Whether it will result in a separate reason code I'm not quite sure, but it
doesn't matter very much.)
The use of the "unspecified" reason code is a deprecated catch-all which
hopefully won't be used.
That leaves us with two serious reason codes, keyCompromise and
cACompromise, three more or less benign reason codes, affiliationChanged,
superseded, and cessationOfOperation, and two transient codes involving
temporary suspension of a certificate pending a more detailed investigation.
In addition to the reason codes, there is also an "invalidity date." The
text states that:
"The invalidity date is a non-critical CRL entry extension that provides the
date on which it is known or suspected that the private key was compromised
or that the certificate otherwise became invalid. This date may be earlier
than the revocation date in the CRL entry, but it must be later than the
issue date of the previously issued CRL. Remember that the revocation date
in the CRL entry specifies the date what the CA revoked the certificate.
Whenever this information is available, CAs are strongly encouraged to share
it with CRL users."
After thinking about that statement,. I am going to recommend that the
wording be changed slightly, to say that the invalidity date is the date by
which it BY WHICH IT BECAME KNOWN or suspected that a compromise occurred.
It is conceivable that a compromise might be suspected, or uncovered during
the course of an investigation, and the investigation might reveal that to a
reasonable degree of confidence, the compromise actually took place a year
ago.
However, it does not make very much sense to allow some to renege on
transactions that took place a year ago, even if the compromise did in fact
occur, for it would allow someone to effectively write a check in
disappearing ink, and repudiate transactions retroactively.
I believe that it would be correct to say that from a legal perspective, the
revocation of a certificate, regardless of cause, or even the complete
absence of a certificate, does not invalidate a digital signature if it can
be established in court that the signer did in fact affix the digital
signature to a particular document, and that he did so with the intent of
being legally bound by the signature.
However, there is also the issue of whether the relying party's reliance on
a digital signature cum certificate chain was commercially reasonable for
the type of transaction that was involved. In other words, a PGP signature,
or a signature backed up by a VeriSign class 1 certificate is likely to be
held to be legally binding if it can be shown that the signature was that of
the putative key holder. But on the other hand, if someone were to rely on
such a signature exclusively to buy a billion dollar oil tanker and the
transaction went bad, the courts would probably hold that such a reliance
was not commercially reasonable, and that the relying party who went ahead
with the transactions did so at his own risk. Caveat emptor.
Clearly the revocation of a certificate because of a key compromise of the
user, or a compromise of a CA, (not necessarily just a key compromise, but
also a breakdown of effective control over the issuance of certificates),
would almost certainly result in the reliance being viewed as not
commercially reasonable, for any and all transactions reliably dated after
the invalidity date. For transactions dated before the invalidity date but
processed for acceptance after the invalidity date, big red flags ought to
go up regarding the commercial reasonableness of the transaction, and if
there is an option to do so the subscriber or subject and/or the CA ought to
be contacted for further details before honoring the transaction, but it is
not necessarily invalid.
With respect to certificates which are revoked for benign reasons, such as
affiliationChanged (which presumably includes a simple change of name or
change of address), or a certificate has been superseded, reliance on such a
certificate is somewhat suspect, in particular if the user in question no
longer has the requisite authority to authorize the transaction (someone is
no longer a purchasing agent, or no longer with the company).
However, if they did have the requisite authority as of the date of the
transaction, then the reliance is probably valid, and at most a yellow flag
ought to go up. If the transaction was dated after the certificate was
revoked, even for a benign reason, the transaction probably ought to be
rejected.
The cessationOfOperation reason code raises a set of different issues. If
the company is no longer in business, then they might not be able to honor
their commitment even if they were technically valid -- another red flag.
Bob
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com
"If you are tring to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross the chasm in two leaps."
Follow-Ups: