Subject: Re: PoP & Signer's User ID subpacket?

From: "Hal Finney" <[email-masked]>
Date: Mon, 16 Jun 2003 16:22:44 -0700

How bad is it to make someone else think that a key is yours, when it
actually is not?  I.e. you have no idea what the private part is.

As Trevor points out, with subkeys especially, that's exactly the
situation.  The only key/person vouching for the ownership of the
subkey(s) is the master key and its owner.  Third-party certification
doesn't cover subkeys, and in fact subkeys can be added even after third
parties sign and certify the master key.

So what can you do with this?  If you claim someone else's encryption
key as your own, it would mean (A) you can't decrypt messages sent to
that key, and (B) someone else could.  (The important point is that it
does not allow the obvious attack of letting you read messages intended
for that person.)

I suppose this could be damaging to the sender in some contrived
scenarios: if the government monitored his outgoing email, they might
find him sending a message encrypted to Osama bin Laden's public key.
He would be the victim of a prank; someone else gave him a key which
had a match to ObL's encryption key on it.  But that's pretty far-fetched.

For signatures, it would mean that (A) you could not sign messages with
that key, and (B) someone else could.

This could mean that a message signed by someone else might appear to be
signed by you.  But that's not so significant, as you could have achieved
the same effect just by copying the plaintext of the message to be signed
and signing it with one of your own keys.  And this also might work to
your detriment, as you could be harmed by some signed statement issued
by someone else, on a key you claimed as your own.

So I don't think that either of these attacks is all that serious,
as long as people understand what they mean and don't draw unwarranted
conclusions.

Hal Finney

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2003 18:50:36 -0700

At 04:22 PM 6/16/2003 -0700, Hal Finney wrote:

>[...]
>and signing it with one of your own keys.

If you have access to the plaintext - but if Bob sends Charlie a signed and 
encrypted message, and Charlie receives what looks like a signed and 
encrypted message from Alice, that's a neat trick on Alice's part, since 
she'll have effectively signed something she never saw.

For example, Charlie says "I'll give twenty bucks to whoever answers my 
riddle".  Alice doesn't know the answer, but makes Bob's signed and 
encrypted answer appear to come from her.

Something similar: what if Alice's signature subkey belongs to a primary 
key that also has an encryption subkey?  Suppose the signature subkey is 
really Bob's key, but the encryption subkey is legitimately Alice's.  Then 
if Charlie receives a message signed by Bob's signature key and containing 
corroborating info, so Charlie is convinced it really came from Bob, 
Charlie might leap to the false conclusion that Alice's encryption public 
key is also associated with Bob.  I.e.:

Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did you 
bury that treasure we stole?"  Charlie replies "If you're really Bob, 
what's our codeword?  And send it to me signed and encrypted, so I'll know 
which public key is yours."  So Bob does.  But Alice now slips Charlie a 
primary key that has Bob's public key as a signing subkey, and Alice's 
public key as an encryption subkey.  Charlie decrypts and verifies the 
message, and is satisfied that the owner of this primary key knows the 
codeword, and is "Bob".  So he encrypts the treasure map to Alice's public key.

In the "riddle" case, Charlie assumed a relation between the signing key 
and Alice's name which Alice could falsify.  In the "treasure" case, 
Charlie assumed a relation between the signing subkey and encryption subkey 
which Alice could falsify.

Before, I suggested adding the "Signer's User ID" subpacket into message 
signatures.  This would work in the "riddle" case, where Alice falsifies 
the name, but not in the "treasure" case, where Alice falsifies the 
relation between subkeys.  Maybe a message signature produced by a subkey 
should also contain a subpacket that gives the primary key ID, so an 
attacker can't present his primary key and someone else's subkey to verify 
someone else's signature.  Haven't really thought this through, though..

Trevor

---

From: Derek Atkins <[email-masked]>
Date: 16 Jun 2003 22:36:58 -0400

Trevor Perrin <[email-masked]> writes:

> Bob emails Charlie and says "Hi, I'm your old friend Bob.  Where did
> you bury that treasure we stole?"  Charlie replies "If you're really
> Bob, what's our codeword?  And send it to me signed and encrypted, so
> I'll know which public key is yours."  So Bob does.  But Alice now
> slips Charlie a primary key that has Bob's public key as a signing
> subkey, and Alice's public key as an encryption subkey.  Charlie
> decrypts and verifies the message, and is satisfied that the owner of
> this primary key knows the codeword, and is "Bob".  So he encrypts the
> treasure map to Alice's public key.

Except that Alice's subkey wouldn't have a self-signature by Bob's
primary key, so it shouldn't be accepted by Charlie as a valid subkey.

> In the "riddle" case, Charlie assumed a relation between the signing
> key and Alice's name which Alice could falsify.  In the "treasure"
> case, Charlie assumed a relation between the signing subkey and
> encryption subkey which Alice could falsify.

Except Alice cannot falsify without the help of Bob.  Why would
bob sign Alice's subkey as her own?

> Before, I suggested adding the "Signer's User ID" subpacket into
> message signatures.  This would work in the "riddle" case, where Alice
> falsifies the name, but not in the "treasure" case, where Alice
> falsifies the relation between subkeys.  Maybe a message signature
> produced by a subkey should also contain a subpacket that gives the
> primary key ID, so an attacker can't present his primary key and
> someone else's subkey to verify someone else's signature.  Haven't
> really thought this through, though..

Without a self-signature on the subkey, how would ie be accepted
as valid?

> Trevor

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2003 20:12:32 -0700

>primary key, so it shouldn't be accepted by Charlie as a valid subkey.

It would have a self-signature by Alice's primary key, but Charlie wouldn't 
know this was Alice's primary key and not Bob's.  In this example, I was 
assuming there's no web of trust, and Charlie doesn't otherwise know Bob's 
primary key.  Charlie is trying to authenticate Bob and determine Bob's 
keys, and knows that if Bob sends him (Charlie) a signed and encrypted 
message containing a "codeword" they both know, then the signing key must 
belong to Bob.

Charlie then makes the reasonable but wrong assumption that the primary key 
and the encryption subkey that he found associated with this signing subkey 
must also belong to Bob.

If the signature on the actual message contained the primary key ID, as a 
hashed subpacket, then an attacker wouldn't be able to associate her own 
primary key with Bob's signing key, so then Charlie's assumption would be 
correct.  I think.

Trevor

---

From: David Shaw <[email-masked]>
Date: Mon, 16 Jun 2003 23:20:35 -0400

> primary key, so it shouldn't be accepted by Charlie as a valid subkey.

I think Trevor was referring to Alice generating a brand new primary
signing key and encryption subkey, and then using the new primary to
self-sign Bob's signing subkey (or transform Bob's primary into a
subkey and self-sign that).  Alice then is in posession of a key that
will correctly verify Bob's signatures, but someone encrypting to the
key will encrypt to Alice.

Alice can't issue signatures as Bob, but can attempt to claim existing
Bob signatures as her own.

David

---

From: Derek Atkins <[email-masked]>
Date: 17 Jun 2003 09:48:31 -0400

> Bob signatures as her own.

Well, the obvious fix for this attack is to require all signing keys
to be authoritative.  If we're going to allow signature subkeys (as
opposed to just encryption subkeys), then the self-signature on that
subkey should be a two-factor signature, requiring BOTH secret keys.

It was unclear from the proposed attack that this was using signature
sub-keys.  I personally believe that signature subkeys are a bad idea,
but if the working group seems to feel otherwise I think we should put
some strong language about the pitfalls.

-derek

---

From: David Shaw <[email-masked]>
Date: Tue, 17 Jun 2003 10:05:30 -0400

> subkey should be a two-factor signature, requiring BOTH secret keys.

Yes.  Hal suggested something similar, but to have the signing subkey
certify the primary.

Does anyone have any thoughts on the details of this?  We already have
all the parts needed to have a signing subkey certify the primary
(just have the subkey issue a 1F signature).  I like your suggestion
to put it in the subkey self-signature since that will avoid the
inevitable messiness when a subkey is deleted, but leaves behind the
1F signature.  Putting it in the subkey self-signature keeps things
neat.

With regards to signing subkeys in general, I'd much rather fix the
problem than drop signing subkeys.  2440 defined signing subkeys years
ago, and they are already in use today (this message is signed by
one).  They are very useful in a good number of situations.  To remove
them now seems like a step backwards.

David

---

From: Derek Atkins <[email-masked]>
Date: 17 Jun 2003 10:13:58 -0400

> Yes.  Hal suggested something similar, but to have the signing subkey

That's not sufficient..  We need both signature keys to cross-certify.
The attack without cross-certification is that I could generate a
signing key and then certify that it's a signing subkey of
[email-masked].

> 1F signature.  Putting it in the subkey self-signature keeps things

I think this is exactly where a notary-style double-signature is
useful (and should be required as a MUST).

> them now seems like a step backwards.

Fair enough..  I don't like it, but we can at least fix the
certification problems.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: David Shaw <[email-masked]>
Date: Tue, 17 Jun 2003 10:37:15 -0400

> [email-masked].

Sorry, I wasn't clear.  I should have said "... in addition to the
current subkey certification from the primary".

> useful (and should be required as a MUST).

So, the primary signs the subkey as before and then the subkey
notarizes (0x50 sig) this signature?  That sounds good, but we'll end
up with two signature packets after the signing subkey.  I'm afraid it
would be likely to confuse pre-2440bis implementations which don't
expect to see that extra signature there.

If we put the subkey-on-primary signature IN the original
primary-on-subkey signature (as a new subpacket), then it won't break
older implementations.

David

---

From: Derek Atkins <[email-masked]>
Date: 17 Jun 2003 11:02:15 -0400

Sure, this is fine... Theoretically the real key owner should have
access to both private keys at the same time, so this shouldn't be an
issue.  Using a subpacket is fine.  I still belive this is a MUST ;)

-derek

---

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 17 Jun 2003 19:26:24 +0200

On Tue, 17 Jun 2003 10:05:30 -0400, you wrote:

>
>[2F17AC17]*** PGP SIGNATURE VERIFICATION ***
>[2F17AC17]*** Hash: SHA1
>[2F17AC17]*** Status: Signing Algorithm Not Supported
>[2F17AC17]*** Signer: David M. Shaw <[email-masked]>
>*** Note: Signing Key is a Sub-Key!
>[2F17AC17]*** Key ID: 0xE2665C8749E1CBC9
>[2F17AC17]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923  2CE6 E266 5C87 49E1
>CBC9 [2F17AC17]*** Signed: 6/17/2003 4:05:30 PM
>[2F17AC17]*** Verified: 6/17/2003 6:55:28 PM
>[2F17AC17]*** BEGIN PGP VERIFIED MESSAGE ***
>
<snip>
>them now seems like a step backwards.
David, I don't think that signing subkeys are a good idea.
Please look at the above verification block.  Furthermore,
I had problems retrieving the signing key from the servers.
So, I grabbed all the keys out there with "David Shaw" as UID.
You probably consider me thick, but there are OpenPGP users
out there who are a lot thicker than I am.
The irony is that, you can achieve the same thing with
a signing master key if you think about it.
I am afraid that signing subkeys are going to be very
expensive to implement.  The whole of the keyserver
infrastructure needs to retro fitted to deal with them.
You are right that 2440 defined signing master keys years
ago, however, to be honest with you, this is my second
encounter with them, and I consider myself a heavy
PGP user.  TIGER192, SHA1x, & HAVAL-5-160, had more
widespread use than signing subkeys, if you ask me.
Yet, we had no qualms about dropping them.
The same should be done for signing subkeys.
The less, the simpler the better.

>David
Best Regards

Imad R. Faiad
>[2F17AC17]*** END PGP VERIFIED MESSAGE ***

---

From: David Shaw <[email-masked]>
Date: Tue, 17 Jun 2003 15:32:23 -0400

> Yet, we had no qualms about dropping them.

Yes, and I agreed with dropping them, but I don't see a real
inconsistency here.  There is a substantial difference between
dropping hash algorithms that were either unused (MD2), or unusable
(TIGER192 and HAVAL-5-160 had no OID, double-SHA was experimental),
and dropping a used feature from a widely deployed implementation.

As it happens, some keyservers (the LDAP ones) support subkey searches
today.  The newer HKP servers (SKS, ONAK) plan to add support soon.
To be sure, PKS doesn't support it, but frankly, PKS also eats keys on
a regular basis.  If we were going to restrict OpenPGP based on what
some of the PKSes out there could handle without choking, we'd have to
throw away v4 RSA and any key with more than one subkey as well. ;)

I think it is poor practice to restrict OpenPGP based on what a single
broken keyserver can handle, especially since there are many
alternatives, including a few fixed versions of PKS.

If you are very concerned about old keyservers not being able to
retrieve a key given a subkey ID, then I would certainly support an
(optional) subpacket or signature notation to be used on signatures
issued by a signing subkey.  The subpacket would contain the keyid of
the primary key, just to make it easier to find on a keyserver.

(I saw you were unable to verify my message with PGP 8.  For some
reason, signing subkeys only work with the "pgpmail" interface and not
the plugins in PGP 8.  I assume it's a bug, and hopefully it'll be
fixed in the next update.)

David