[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delegation question

>>>>>> "Bob" == Bob Jueneman <BJUENEMAN@novell.com> writes:
>    Bob> Consider a gedanken experiment. Suppose Bob issues the certificate
>    Bob> to Cliff, valid for one year.  Then a week later, Bob leaves to
take
>    Bob> a job elsewhere, and his company revokes Bob's certificate
>    Bob> (PKIX/X.509 or SPKI -- it doesn't matter).  Should that invalidate
>    Bob> Cliff's certificate?
>
>    Bob> No, because Cliff is not dependent upon Bob's on-going patronage
>    Bob> (I'll assume for the sake of argument, at least), but rather on
>    Bob> Bob's having validly exercised a role granted/delegated to him by
>    Bob> their common employer.  The same reasoning presumably applies to a
>    Bob> certificate issued by Alice.
>
>    Bob> It may be convenient, and certainly easier to verify the
correctness
>    Bob> of the certificate chain if the validity period of a certificate
>    Bob> issued to a subordinate entity is a proper subset of the validity
>    Bob> period of the issuing authority, but it isn't absolutely required.
>    Bob> Sufficient, in other words, but not necessary.
>
>    Bob> In both the PKIX and SPKI environments, it may be useful to limit
>    Bob> the duration of time in which authority can be delegated, but
>
>  To implement this in SPKI, my impression is that is requires some kind of
>secure timestamp put in the certificate that is issued to Cliff by Alice to
>prove that Alice made the certificate during her week of authority.
>
>  Right now, the verify need trust only its own clock for validity checks. 
>  Is there another way to get the behaviour that Bob describes without
having
>the verifier trust other clocks?

Again, this is the classic nonrepudiation problem.  If you as the relying
party want to protect against the possibility the signer would attempt to
repudiate a signature after the fact by claiming that her key was stolen,
and that the miscreant backdated the signature, then you have to get a
trusted timestamp on the document that is contemporaneous with the time of
its execution. You may also have to get a trusted timestamp on the signer's
certificate (the entire chain, if you are really paranoid), in order to
prove that the signer hadn't revoked the certificate before you received the
transaction.  (That still doesn't prove that the alleged key holder did or
did not sign the document, but it may shift the burden of proof to the other
side).

I don't see a grant of authority as being any different.

But in most circumstances, Cliff is not saddled with the responsibility of
proving that Alice acted within her authority.  Particularly within the US,
there is an ever-increasing doctrine of implied authority.  That is, if
someone claims to have a certain amount of authority (e.g., represents
himself as a purchasing agent, or even a CEO), and the relying party has no
readily available way to know that representation was not correct and acts
prudently and in good faith, then the person who claimed to have the
authority may be personally liable for any damages incurred. If the person
did in fact work for or was otherwise affiliated with the company in whose
name the order was placed, then the company is probably on the hook for the
goods, and they can not only fire the person who misrepresented his
authority, but collect any damages from them as well. The relying party is
generally not required to take extraordinary steps to detect and avoid a
potential abuse of authority, because it doesn't happen very often.

So Cliff is probably in the clear, assuming that he didn't conspire with
Alice.  Alice may be in trouble with Bob if it can be proved that she
violated her authority, but the proof does not necessarily have to involve
iron-clad, cryptographically established evidence.  Simple
"preponderance-of-the-evidence" would probably suffice, including e-mail
logs, etc.

In other words, this "problem" may not absolutely require a
cryptographic/certificate type of solution.

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."