Subject: PoP & Signer's User ID subpacket?

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2003 14:34:26 -0700

I could be wrong, but it seems like PGP keysigning often happens without 
Proof-of-Possession of the corresponding private key.  For example, at PGP 
keysigning parties, I think it's common for people to attest that a 
fingerprint really belongs to them, but not have to produce signatures with 
the corresponding private key.

Is there a risk that Alice could trick someone into certifying that Bob's 
public key belongs to her?  Then someone receiving a signed message from 
Bob might incorrectly think it came from Alice.

Maybe, as a Security Consideration, the "Signer's User ID" subpacket should 
always be included in signatures.  If Bob always included this subpacket in 
his signatures, then no-one could be tricked into thinking Bob's signed 
messages really came from Alice.

Trevor

---

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

> the corresponding private key.

That is true.  Some people (like me) send a challenge to the email
address in the user ID, and require that the key owner sign the
challenge before I'll sign the key.  There are a few variations on
this basic idea, some more rigorous than others.

> Bob might incorrectly think it came from Alice.

Not really, since when Charlie certifies key X, he isn't certifying
that it belongs to anyone other than the string in the user ID.
Assuming Bob doesn't have a user ID "A-L-I-C-E", this shouldn't be a
problem ;)

Of course, it is possible for Alice to attach her own name to Bob's
key as a second user ID, but that user ID wouldn't be selfsigned and
so it would be difficult to get someone else to sign it.

David

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2003 15:53:11 -0700

At 06:08 PM 6/16/2003 -0400, David Shaw wrote:

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

Probably Alice would first ditch Bob's self-signed user ID, then add her 
own name as an unsigned user ID.  How software would display that, and 
whether users would recognize the danger signs and not sign that, I dunno.

But here's another angle: suppose Alice gets someone to sign her legitimate 
primary signing key.  Then she signs Bob's public key as a subkey of her 
primary key.  So even if you've done a Proof-of-Possession check on Alice's 
primary key, she can possibly evade that by introducing a subkey.

I'm too lazy to spend a nice summer day testing this, but from the draft it 
seems like it might work.  So I still like encouraging use of the "Signer's 
User ID" subpacket in the Security Considerations.

Trevor

---

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

On Mon, Jun 16, 2003 at 03:53:11PM -0700, Trevor Perrin wrote:

> >> Is there a risk that Alice could trick someone into certifying
> >> that Bob's public key belongs to her?  Then someone receiving a
> >> signed message from Bob might incorrectly think it came from
> >> Alice.
> >
> >Assuming Bob doesn't have a user ID "A-L-I-C-E", this shouldn't be
> >a problem ;)
> >
> >key as a second user ID, but that user ID wouldn't be selfsigned
> >and so it would be difficult to get someone else to sign it.
> 
> Probably Alice would first ditch Bob's self-signed user ID, then add
> her own name as an unsigned user ID.  How software would display
> that, and whether users would recognize the danger signs and not
> sign that, I dunno.

PGP shows such user IDs as revoked (not sure why) and refuses to sign
them.

GnuPG shows such user IDs as unsigned, and warns the user before
signing them.  I may go ahead and make the warning even stronger or
just flat out refuse to sign like PGP.

This raises a 2440bis question: given all the recent deprecation of
PGP 2.x stuff, is it worth requiring self-signatures on user IDs now?
If I recall, the only reason that user ID self-signatures are not
currently required was for 2.x compatibility.  Certainly every modern
implementation (5.0+, any GnuPG) generates user ID self-signatures
automatically when a user ID is created.

> But here's another angle: suppose Alice gets someone to sign her
> legitimate primary signing key.  Then she signs Bob's public key as
> a subkey of her primary key.  So even if you've done a
> Proof-of-Possession check on Alice's primary key, she can possibly
> evade that by introducing a subkey.

At least one of the challenge policies (mine) requires that the
challenge response comes from the primary key.  The primary is the one
that I got a fingerprint for, and the primary is the one I'm signing
when I certify the key, so the primary is the one I require the
challenge response from.

David

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Jun 2003 21:47:59 -0700

>when I certify the key, so the primary is the one I require the

Right, but after you've done this, and checked that Alice really possesses 
her primary private key, Alice can certify a subkey whose private key she 
doesn't really possess.

The problem is that there's a forward-linkage from a primary key to a 
subkey, but no back-linkage from a signing subkey to the primary key.  Hal 
suggested having the signing subkey also certify the primary key.  I 
suggested having the signatures produced by the signing subkey have the 
primary key's ID as a hashed subpacket.

Trevor

---

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

> her primary private key, Alice can certify a subkey whose private key she 

Right, but if/when we fix this problem, then all of the certifications
I've made already are still correct (as I ensured it was a primary
that signed the challenge).

> primary key's ID as a hashed subpacket.

Yes.  There are pros and cons, but on balance I like Hal's solution a
bit better as it only needs to be done once, presumably at key
generation time.  The subpacket solution needs to be done every time
the signing subkey issues a signature.

The subpacket solution does have a nice side effect in that it becomes
possible to always know the primary key when looking at a subkey
signature.  Since most keyservers don't support search-by-subkey yet,
this could be handy.  Still, having the subkey sign the primary seems
cleaner.

David

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Jun 2003 13:05:04 -0700

At 08:30 AM 6/17/2003 -0400, David Shaw wrote:

> > [...]
>this could be handy. [...]

Another slight advantage is that the relying party doesn't have to verify 
an extra signature.  Also, pre-existing keys with signing subkeys wouldn't 
have to be modified, they could just start issuing signatures with this new 
subpacket.  (On the other hand, with the solution you and Hal advocate, if 
you *do* modify the key by adding a back-signature, then pre-existing 
message signatures can take advantage of it, so maybe this is a wash).

Either solution seems fine.  You also mentioned requiring self-signatures 
on user IDs, which seems like a good thing to insist on, and pretty much 
takes care of the proof-of-possession concern I was raising, I think.

Trevor