William H. Geiger III, <whgiii(_at_)invweb(_dot_)net>, writes:
Hmmmmm I am going to present a senario below and see if this follows your
logic here:
User 1 generate a KeyPair.
User 1 self-signs (Sig1) his Public Key (Pub1) with the private key
(Sec1).
In Sig1 he make's the sig non-revokable and the key revokable by User 2's
key (Sec2).
Now Sec1 is comprimised and User1 may not have a copy of Sec1 after the
comprimise.
User 1 notifies User 2 of the comprimise. [This presents an interesting
senario in itself of how does one notify User2 if the key used for
authentiaction is comprimised <g>].
[This would have to be done by out of band means, similar to how he would
identify himself to get his key signed by another party.]
User 2 issues the revoke certificate (Revoke1) using Sec2.
Revoke1 is accepted by Pub1 because of the 3rd party revoke flag in Sig1.
The holder of the comprimised Sec1 can not prevent this as Sig1 is marked
as non revokable.
This is a good explanation. Thanks for providing it. There has been so
much attention paid to the additional recipient feature that few people have
had the energy to look at the other new features.
I think I understand the service you are trying to provide but to be
honest it does not give me any warm fuzzies thinking about it.
What does one do if Sec2 rather than Sec1 is comprimised?
In that case Sec1 could be revoked improperly, and the keyholder would
have to create a new key. This is a denial of service attack rather
than a security breach. No encrypted messages to Sec1 could be read.
So it is a less damaging attack.
What does user1 do if he whishes to change the status of the preferences
in his self signature? Say he no longer wishes for User2 to have revoke
powers, or User2 needs to change his revoke key (Sec2)?
He would have to have two self signatures, one holding the third party
revocation grant, and one holding his preferences.
Also how should the non-revoke flag interact with the experation flag?
Which should take presedent? Should a non-revokable signature be treated
as non-expirable?
The non-revoke flag says that there will be no revocations. It does
not say anything about expirations, so there is no reason to think it
should be non-expirable. Look at it this way: since they are in the
same signature, the same author must have created both the expiration
and the non-revocation. The reasonable interpretation is that he wanted
the signature to expire at the specified time, but he wanted it to be
non-revocable prior to that time.
I think that a detaled explination of this subtype is warrented along with
it's inteded use and where it should never be used. Improperly implemented
this feature could cause all kinds of havok. Things like the non-revoke
flag being set on signatures other than self-signatures with the 3rd party
revoke being set.
We have not attempted to give detailed explanations of the intented
uses or motivations of any of the features in the spec. The spec
simply defines the syntax and semantics. There have been suggestions
that we need a companion document to define rationale for the various
features, which could be a follow-on project. It seems to me though
that almost every section of the spec deserves a page or more describing
the motivations, the purpose, security considerations, things to watch
for, etc. So a rationale doc would probably considerably larger than
the spec, and its creation will be a large project.
Hal