[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delegation question
>I'm having difficulty figuring out how SPKI solves the following problem of
>delegation:
>
>Bob has been delegated the authority to sign certificates allowing
>employees to enter his company's building. He will be on vacation for
>a week, so he delegates his building entry authority, with delegation, to
>Alice for a period of one week. During the week, Alice signs a building
>entry certificate for Cliff. It seems that Cliff's authority to enter the
>building will expire with Alice's certificate. Is there a way to make it
>persist? I can't see how to do this with any combination of capability and
>name certificates. Am I missing something?
>
>--
>Steve Koehler
>Secure Computing Corporation
>koehler@securecomputing.com
>
>
This is a classic case of nonrepudiation.
The issue is not whether the issuer of some capability still has that right
at some arbitrary time in the future, but whether they legitimately had the
right at the time it was exercised.
Consider a gedanken experiment. Suppose Bob issues the certificate to Cliff,
valid for one year. Then a week later, Bob leaves to take a job elsewhere,
and his company revokes Bob's certificate (PKIX/X.509 or SPKI -- it doesn't
matter). Should that invalidate Cliff's certificate?
No, because Cliff is not dependent upon Bob's on-going patronage (I'll
assume for the sake of argument, at least), but rather on Bob's having
validly exercised a role granted/delegated to him by their common employer.
The same reasoning presumably applies to a certificate issued by Alice.
It may be convenient, and certainly easier to verify the correctness of the
certificate chain if the validity period of a certificate issued to a
subordinate entity is a proper subset of the validity period of the issuing
authority, but it isn't absolutely required. Sufficient, in other words,
but not necessary.
In both the PKIX and SPKI environments, it may be useful to limit the
duration of time in which authority can be delegated, but without
invalidating certificates which were issued during that period. In the PKIX
model, this can be accomplished by setting the expiration portion of the
privateKeyUsagePeriod to some conveniently short date, much shorter than the
general expiration date. This would prevent Alice from using her delegated
powers after Bob is expected to return, with perhaps a day or two grace
period, without invalidating any previously issued valid certificates.
It should also be remembered that (at least in the PKIX environment), the
certificate validity period is used to define when the CA's responsibility
for maintain accurate certificate status information (via CRLs or otherwise)
expires. It does NOT say anything about whether a digital signature should
no longer be considered valid after that date. Although some people would
argue that trust should slowly decline with time, the generally accepted
paradigm is that if a signature was valid and binding at the time it was
made, then it is valid and binding into the indefinite future, regardless of
the potential revocation or expiration of the certificate. Of course, the
fact that a certificate has expired might very well cause the relying party
to think a little more about whether to accept the transaction -- i.e., is
it still a commercially reasonable transaction if the date is stale? This
is the same principle that is applied to checks that may be presented for
payment a year after they were written. They aren't necessarily invalid, but
they might reasonably be refused by a relying party.
Hope this helps.
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 trying 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: