RE: Primary subkey subpacket

Ian Brown <> Wed, 14 August 2002 07:53 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id DAA29632 for <>; Wed, 14 Aug 2002 03:53:39 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id g7E7j6l11072 for ietf-openpgp-bks; Wed, 14 Aug 2002 00:45:06 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with SMTP id g7E7j5w11068 for <>; Wed, 14 Aug 2002 00:45:05 -0700 (PDT)
Received: from by with UK SMTP id <>; Wed, 14 Aug 2002 08:44:47 +0100
From: Ian Brown <>
To: ietf-openpgp <>
Subject: RE: Primary subkey subpacket
Date: Wed, 14 Aug 2002 08:44:56 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

Werner Koch wrote:
> 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.

(and Adam Back and Ben Laurie's. They're at, 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?