-----BEGIN PGP SIGNED MESSAGE-----
In
<199712301801(_dot_)KAA04145(_at_)s20(_dot_)term1(_dot_)sb(_dot_)rain(_dot_)org>,
on 12/30/97
at 01:01 PM, Hal Finney <hal(_at_)rain(_dot_)org> said:
I also have some problems with some of the signature subpackets.
- -- Revokable
Is it really appropriate to have a signature that can not be revoked?
This was intended to be used along with the third-party revocation
mechanism. This allows you to specify that some third party key has the
power to revoked your key. People are constantly forgetting their
passphrases and are unable to revoke their own keys. This will allow
them to request a revocation from a designated third party.
However if this third-party authorization self-signature were itself
revocable, then someone who stole the secret key could revoke the
third-party revocation authorization, making any attempt by the third
party to revoke the key be ineffective. So at least in this case it
makes sense for the third party revocation authorization self signature
to be irrevocable. Given one use, more may be discovered, so I thought
it should be a separate subpacket.
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>].
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.
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?
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)?
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?
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.
- --
- ---------------------------------------------------------------
William H. Geiger III http://users.invweb.net/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html
- ---------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNKpYWY9Co1n+aLhhAQGZ3wP/c9AJfqGXztnu+fBeC24X4Ucskxc3YHTw
kz1TOorWV7jCqBcEkqK6b5vUrZO5gRcPOP23N8OGGrdxhNN2AbvbfuOnuk5/ieLM
yfXv4jMXcOrbYiE4bFNjv0trFu2Lwy90IZJIRBqQaAZsS+4odZIe4wQSyyyXP1ya
Z4OE/koOBuc=
=XJWL
-----END PGP SIGNATURE-----