Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt

David Shaw <> Tue, 13 August 2002 22:39 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA24197 for <>; Tue, 13 Aug 2002 18:39:58 -0400 (EDT)
Received: by (8.11.6/8.11.3) id g7DMXfh07658 for ietf-openpgp-bks; Tue, 13 Aug 2002 15:33:41 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g7DMXew07654 for <>; Tue, 13 Aug 2002 15:33:40 -0700 (PDT)
Received: (from dshaw@localhost) by (8.11.6/8.11.6) id g7DMXcZ14869 for; Tue, 13 Aug 2002 18:33:38 -0400
Date: Tue, 13 Aug 2002 18:33:38 -0400
From: David Shaw <>
To: OpenPGP <>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Message-ID: <>
Mail-Followup-To: OpenPGP <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-Phase-Of-Moon: The Moon is Waxing Crescent (30% of Full)
User-Agent: Mutt/1.5.1i
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Mon, Aug 12, 2002 at 11:14:49PM -0700, Jon Callas wrote:
> > I think that it would be nice to have the NAI X.509 packets documented.
> > Having quasi-offical data formats that implimentors need to deal with, but
> > are not documented, sounds like a bad idea to me. (Though, if it belongs
> > in a seperate Internet Draft, I have no problem with that. But there
> > should be some place to go other than the PGP source for this
> > information.)
> It would be nice, but we have to get the owners of that code base to be
> willing to document it, or have someone else do it. I presume there's
> consensus that this is a good idea, as there are no further comments?

To a certain extent these are already documented in the draft.  The
X.509 signature subpackets are in the "private or experimental" range
(they use 100), and the signatures are also issued using public key
algorithm 100, also experimental.

It would be nice to see the format fully documented, though if it were
widely adopted, it would result in one of the experimental values
effectively losing its experimental status.

> I want to get soon a new RFC number, so let's look at what there is to
> finish up.
> * I've completely spaced on the notary signatures, apparently, so I'll get
> those in soon. 

I've started roughing out some code for this (based on the discussion
a few weeks ago) so we can have some implementation experience for
this and the "revocation target" subpackets.  Could you post the
notary signature draft language when you put it together?

> * I'll look at signature subpackets, and if the spec needs changes to jibe
> with reality, I'll do it. MUSTs changed to SHOULDs, right?

Yes, and the "two or more" subpacket requirement for the hashed
section should probably be "zero or more".


   David Shaw  |  |  WWW
   "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