Subject: Primary subkey subpacket

From: Timo Schulz <[email-masked]>
Date: Tue, 13 Aug 2002 23:58:44 +0200

Hi!

Recently I stumbled over a problems with multiple subkeys. I know
PGP doesn't let the user choose the key at all and GPG uses the
newest key by default. What about a "primary subkey" subpacket
which is placed on the self signature to force the implementation
to use a special subkey. The format should be similar to the 
"primary user id" packet.

        Timo

---

From: David Shaw <[email-masked]>
Date: Tue, 13 Aug 2002 18:36:02 -0400

> "primary user id" packet.

This is interesting.  You'd have to tie it to the key flags subpacket
somehow, as the notion of "primary" is different for different key
types (primary signing subkey, primary encrypting subkey, etc.)

It could even be a bit set in the key flags subpacket itself.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Werner Koch <[email-masked]>
Date: Wed, 14 Aug 2002 09:14:56 +0200

> newest key by default. What about a "primary subkey" subpacket

I don't think this is needed.  If a subkey is published a sending
implementation may choose any of the valid subkeys for encryption.
Although not specified in OpenPGP, it should select the newest one as
long as it has no creation date in the future.

Having such a default subkey flag would inhibit automatic key
rollover.  If we really want to specify handling of subkeys we should
first discuss Ian Brown's suggestions for PFS.

Shalom-Salam,

   Werner

---

From: Ian Brown <[email-masked]>
Date: Wed, 14 Aug 2002 08:44:56 +0100

> first discuss Ian Brown's suggestions for PFS.

(and Adam Back and Ben Laurie's. They're at
http://www.cs.ucl.ac.uk/staff/I.Brown/draft-brown-pgp-pfs-03.txt, although
the draft has expired.)

Briefly, we suggested that for perfect forward secrecy, the subkey closest
to its expiration date should be used. This is because the owner can wipe
that subkey soonest, reducing the possibility that an attacker with a copy
of the message ciphertext will then be able to get the subkey required to
decrypt it.

The draft's progress has stalled as the IESG liked the idea and suggested we
go for standards track rather than informational publication; but I think
they are waiting from some positive response from the working group on that.
Do people think it's worth pursuing, either as informational or standards
track? John Noerenberg thought it might be useful to split the document into
a small standards track document defining the subkey flags we suggest (or
even incorporate that into the rfc2440-bis draft, although we're likely too
late for that now) along with a longer informational draft on using the
protocol features for PFS. But we weren't sure if this more convoluted route
was more useful.

Any thoughts?

Thanks,

Ian

---

From: David Shaw <[email-masked]>
Date: Wed, 14 Aug 2002 13:05:53 -0400

> long as it has no creation date in the future.

I imagine a primary subkey flag as more of a tie-breaker.  If an
implementation wanted to ignore the flag (whether for PFS or other
reasons), that would be fine.  If the implementation did not care, or
could not reach a decision, the primary subkey would be chosen.

David