[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Validity periods can be handled more explicitly
>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 guess we all think that only (c) applies, but there is a lot of
>confusion out there.
I can't speak for all people who are trying to use X.509 certificates, but I
believe that the lack of understanding is in your end of the boat.
>From a technical standpoint, the validity period means precisely one thing,
and one thing only. To quote the PKIX part1-06 document, "The certificate
validity period is the time interval during which the CA warrants that it
will maintain information about the status of the certificate, i.e., publish
revocation data." Period. So the correct answer to your question is, "None
of the above."
To address your particular points:
a. Public keys never expire, they are valid for all time, in that they
permanently bound via mathematics to the private key. Likewise, public keys
can never be compromised -- they are intended to be published, and hence
compromised at birth. Private keys, on the other hand, may have a specified
validity period, after which it is normally expected that they will be
zeroized to prevent the possibility of a compromise. That's why PKIX defines
a privateKeyUsagePeriod. Obviously if you receive a document that appears
to have been signed after the expiration of the privatekeyUsagePeriod, you
ought to look at it very carefully..
b. The identity (and other attributes) contained in a certificate do not
"expire", because they are only represented as being valid as of a single
instant in time, in the first place, i.e., as of the time the certificate
was issued. There is _no_ positive duty or obligation placed on a CA to
maintain a continual awareness of the status of the identity of the user and
report such to potential relying parties, nor any of the other attributes in
the certificate, for that matter. Likewise, there is no legal obligation
placed on the user to notify his CA of a change of name, address, or other
attributes, including identity. From a legal perspective, if you had a
given identity on that date, then you had it. You may subsequently lose a
particular role, you may get married and change your name, and you might do
a lot of other things that would make it desirable to update your driver's
license, business cards, etc., but that doesn't invalidate your signature,
because you are still YOU. If you signed something implying that you had a
particular role and you no longer have that role, you may have just made
yourself personally liable for a transaction made on behalf of your company,
but that is your problem, not the relying party's.
c. The above statement also apply to the link between the public key and the
certificate attributes. They are what they are, and what they were.
In that sense, a signature on an assertion (or anything else, assuming it
reflects the signer's actual intent to sign) represents an immutable
assertion that is valid through all of space time. However, that does NOT
mean that the confidence that you should impute to that assertion is
invariant. "Stuff" happens, including the gradual cooling of the universe,
the decline in strength of a given key length as computing resources
increase, etc.
I ought to underscore this point one more time, from a legal perspective
(although I am not an attorney). The expiration of a certificate, or even
the explicit revocation of a certificate, does not affect the validity of
the digital signature in the slightest. It just makes it harder to prove,
and it probably serves to shift the burden of proof to the relying party.
If the relying party can prove (under the preponderance of the evidence
rule, not a mathematical certainty proof) that you did in fact sign the
document, and intended to do so, then the fact that the certificate had
expired or that had been revoked does not change the _fact_ that you legally
signed the document.
In some jurisdictions, notably those that have chosen to follow the Utah
model, then (assuming the certificates was issued by a licensed CA), the
relying party is entitled to a reputable presumption that the signature is
that of the subject, assuming the certificate chain is valid. If the
certificate chain is not valid, e.g., because a certificate has expired ro
been revoked, then the rebutable presumption does not apply, and the relying
party has a harder burden of proof.
By the way, this rule applies even in the case of a detected forgery. In
that case, it is the forger who is liable, and not the subject of the
certificate, because it was the forger who signed the document, no matter
what the certificate said. But this is obviously harder to prove, and even
if proved, doesn't provide an easy way to find and put handcuffs on the
forger.
Bob
>
>It is important to see that a signature on an assertion defines an
>assertion that is valid throughout all space-time, NOT an assertion
>whose truth varies through time. Consider the SPKI-style certificate
>assertion:
>
> The owner of public key PK1 is allowed to access resource R
> during the period P
>
>This assertion is true throughout time. For example we can come back
>after period P and, using the truth of this assertion, check that some
>earlier access was valid.
>
>So my simplification is to remove the validity period from the certificate.
>Instead define a sufficiently powerful assertion language that allows the
>validity period to be explicitly expressed in the assertion about the
>public key that constitutes the SPKI certificate.
>
>While this really only moves the complexity to a different place, it moves
>it to the right place, and thus makes it easier for the people writing
>and using software that uses certificates to understand exactly what they
>are meant to mean.
>
>Bob Smart
>
>Bob.Smart@cmis.csiro.au Distributed Systems
>CSIRO Mathematical and Information Sciences phone: +61 3 9282 2625
>723 Swanston St, Carlton VIC 3053, Australia fax: +61 3 9282 2600
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: