Re: Suggestion for the signing subkey problem



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Ian,

Alice and Bob use OpenPGP to securely communicate
with each other.  They both are prolific with
their use of subkeys for signing and encryption.

1)  Eve obtains Alice's public key.
2)  Generates a Master Key with as many of
    the attributes as Alice's master key.
3)  She then extracts all the public subkey
    which are Alice's key and binds them
    to the Master Key generated in 1).
4)  She generates a signing subkey.
5)  She then generates an encryption
    subkey, in such a way so that it will
    be the most likely one to be used
    by an OpenPGP implementation.
6)  She performs steps 1) through 5),
    with Bob's key in mind.
7)  Both fake keys are then submitted to
    the keyserver.
8)  She sit in the middle intercepting
    and forwarding Alice's messages
    to Bob and vise versa.
9)  She sends a message to Bob, which
    is at least signed with the signing
    subkey of Alice's fake key.  Does
    the same with Alice using the signing
    subkey in Bob's fake key.
10) Alice and Bob thinking that the other
    party must have generated yet another
    subkey update their copy from the servers.
11) In both cases the message authenticates,
    giving credence to the respective fake keys.
12) In the worst case scenario, Alice
    and Bob, will start using the other's
    fake key, while each is ignorant
    that the other party is using his fake
    key.  Since, Eve is in the middle,
    decrypting the messages, then
    re-encrypting and forwarding them to
    the other party.

I know that the above may not be the
best.  But, I am sure, that someone,
with better skills than mine, can refine,
or come up with one which is a lot more
effective than the above.

The above sounds implausible to you?
Think again, while you think that you know
what you are doing, most OpenPGP users
don't, so don't trust that they do.
No fool is going to attack the cryptographic
aspect of OpenPGP.  Subkeys, used incorrectly,
gives yet another avenue for a would be attacker,
to exploit the vulnerabilities of the user.
Please read this:-
http://home.earthlink.net/~cortana/johnny.pdf
The users are finding hard to understand
the simple aspects of OpenPGP.
The user interface has yet to evolve
to present such simple aspects to the
user in an easily understood manner.
I wish that someone from say the PGP team,
can comment on the impact of the prolific
use of subkeys on the user interface of their
software.  OpenPGP is not a Diffie-Hellman
key exchange protocol, people are in the
middle of it, and they do err...
Now, which you do you prefer, more bells
and whistles, which will be mis-understood,
and mis-used, or less which is better
understood, and more likely to be used
in a more idiot proof manner.

There are a spectrum of solutions.
On the one extreme there is the scalpel school of
thought which believes that if something
is questionable, you get rid of it altogether,
to put my suggestion on the Master key/ one
subkey restriction, into perspective.  It does
not mean that I belong to the "scalpel school of
thought".  Nor do I profess such a proposed solution
as a religion...  I could care less what the adopted
solution is, as long as it addresses the root of
the problem to my satisfaction.

David Shaw's patch, does not solve the problem.

Why shouldn't subkeys be regarded like any other
keys.  What applies to key, should apply to them
too.

my 2c

Best Regards

Imad R. Faiad

On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:

I am amazed that this thread is still running several weeks

after you

started it, with virtually every response refuting your arguments...

And what amazes me, is that you have yet to grasp what we are 
talking about!  Please re-read the thread, some issues have 
been addressed.  I sincerely hope that you re-read each and 
every message in that thread, because, you are taylor made 
for the kind of attacks which can be inflicted to your OpenPGP keys.


I've read all the messages. Your request that subkey capability be
essentially removed has been rejected by all of them.

RFC 2440 was published five years ago. I look forward to your draft 
removing multiple subkey capability from it.

I am no paper pusher, and do not have the funding or 
time/ability to publish RFC's


So I guess this thread is at an end then, with the capability remaining.