Subject: Notary sigs again

From: David Shaw <[email-masked]>
Date: Fri, 28 Mar 2003 09:47:22 -0500

I've been roughing notary signature support into GnuPG, and I'd like
to suggest a simple change for the next draft:

Section 5.2.1 defines notary signatures as:

   This signature is a signature over some other OpenPGP signature
   packet.  It is a notary seal on the signed data.

I'd like to change "packet" to "packet(s)" (or other text that means
the same thing).  It is handy to be able to notarize several
signatures in one place.

David

Date: Fri, 28 Mar 2003 09:47:22 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Notary sigs again
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I've been roughing notary signature support into GnuPG, and I'd like
to suggest a simple change for the next draft:

Section 5.2.1 defines notary signatures as:

   This signature is a signature over some other OpenPGP signature
   packet.  It is a notary seal on the signed data.

I'd like to change "packet" to "packet(s)" (or other text that means
the same thing).  It is handy to be able to notarize several
signatures in one place.

David

Date: Tue, 25 Mar 2003 12:05:20 +0100
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Subject: Re: Hard expiration dates (was: I-DACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Sender: [email-masked]

On Mon, Mar 24, 2003 at 02:10:40PM -0800, Jon Callas wrote:
> On 3/24/03 9:07 AM, "Michael Young" <[email-masked]> wrote:
>> Jon Callas noted:

>>> The V4 fingerprint *includes* the creation time of the key, which is in most
>>> people's opinion, a flaw.

>> Could you say why people thought this was a flaw?

[...]
> Here's the central question: If Alice and Bob each have a key that by some
> coincidence share the same key material, should their keys have the same
> fingerprint?
[...]
> Suppose Bob takes the key material from Alice's key, and makes a new key
> (which he doesn't have the private key to), and claims that one of Alice's
> signatures is actually his own. There is no easy way to figure out what's
> going on. If the fingerprints were the same, it'd be a snap.

Having the fingerprint depend solely on the key would not totally rule
out this kind of attack, however.  It's still easy to derive related
keys such that at least some signatures remain valid.  (For DSA,
inverting the public key value  y  modulo  p  will yield a new public
key value for which 50% of signatures are still valid, namely those
for which the exponent of  y  in the verification equation is even.
Also I wouldn't want to rely on all software rejecting MPIs with extra
leading zeros -- an easy approach to creating an equivalent but
differently looking key is to represent the key differently without
actually changing the values.)

There may be signature schemes designed to avoid the "key stealing"
attack that you described, but this is not part of the usual security
notion for digital signatures, and certainly DSA is not safe in this
respect.  If you think that this is a flaw, then you should be aware
that changing the fingerprint algorithm does not avoid it; we'd also
have to pick appropriate signature schemes.

I don't really think that OpenPGP has a problem here.  (Bob's key with
Alice's key material won't have a valid self-signature anyway.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Tue, 25 Mar 2003 13:51:17 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Hard expiration dates (was: I-DACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

>The reason is that if you have two keys that have the same key material, they
>will have different fingerprints (unless they also have the same date).

It's an inherent conflict in the way PGP identifies keys: To identify a key
for use, you want to identify a unique instance of the key
{key_value,owner,date,etc}.  To identify a key for revocation, you want to
identify all instances of the key {key_value}.  Other key management systems
(e.g. X.509) have the same flaw - you can't use the same ID type for both key
use and key revocation.  (X.509 is in theory supposed to work around this by
only having a single cert for a key, but in practice people just reuse the
same key for everything, so it doesn't work there either).

Peter.

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: What's the consensus?
Date: Mon, 24 Mar 2003 18:35:34 -0500
Sender: [email-masked]

"Jon Callas" <[email-masked]> writes:
> Here are some proposals for changes that I think are reasonable

I generally agree.

> * IDEA gets marked as a MAY from a SHOULD. An implementation note gets put
> in noting that it's patented, but used in PGP 2.

I'd still say that it's the default "preferred" algorithm for v3 keys
(that vast majority that don't have a v4 self-signature :-).

> * We deprecate V3 keys. Specifically, we say {MUST|SHOULD} NOT be generated,
> and {SHOULD|MAY} use. V3 signatures {MUST|SHOULD} not be generated. I lean
> toward SHOULD rather than MUST, but that's only because I'm a gradualist.

I also favor SHOULD.  (I wouldn't want to call an implementation non-compliant
for providing PGP2 interoperability, even as a default.)

> * It sounds like the consensus on hard key expiration is that it needs to go
> into a V5 format.

It is certainly stronger there.  (I don't feel a need for the weaker form.)

> * There are a number of implementation notes that I believe are old enough
> to go away. Given that RFCs, even if obsoleted, do not disappear, deleting

Curiously, I feel much more comfortable dropping PGP5 notes than PGP2.

Date: Mon, 24 Mar 2003 18:33:48 -0500
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: What's the consensus?
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Mon, Mar 24, 2003 at 02:28:46PM -0800, Jon Callas wrote:
> 
> Here are some proposals for changes that I think are reasonable, based on
> what I'm hearing here:
> 
> * IDEA gets marked as a MAY from a SHOULD. An implementation note gets put
> in noting that it's patented, but used in PGP 2.

I think the existing text in bis-07 has it as a MAY already, but
either way, agreed.

> * We deprecate V3 keys. Specifically, we say {MUST|SHOULD} NOT be generated,
> and {SHOULD|MAY} use. V3 signatures {MUST|SHOULD} not be generated. I lean
> toward SHOULD rather than MUST, but that's only because I'm a gradualist. If
> someone feels strongly that we should say MUST, just say so. Also, provide
> comments on this.

SHOULD, MAY, and SHOULD.  Specifically, V3 keys SHOULD NOT be
generated, and MAY be used.  I prefer MAY be used rather than SHOULD
as it makes it easier to have an OpenPGP implementation with no V3 key
support at all.

V3 signatures SHOULD NOT be generated.  Using MUST NOT here would hurt
interoperability with versions of PGP that won't accept V4 signatures
on data (just keys).

A few weeks ago, someone suggested dropping all discussion of V3
keys/signatures from the draft altogether using the rationale that an
implementation could be "1991 and 2440 compliant" instead of just
"2440 compliant" if it wanted to support V3 keys.  I'm okay with that
suggestion as well.

> * It sounds like the consensus on hard key expiration is that it needs to go
> into a V5 format.

Agreed.  I'd also suggest that this stay out of 2440bis.  There is
plenty of time for another draft where V5 keys can be properly hashed
out.

> Other issues:
> 
> * There are a number of implementation notes that I believe are old enough
> to go away. Given that RFCs, even if obsoleted, do not disappear, deleting
> one is not a tragedy. I believe, for example, that anyone still using PGP
> 5.X really shouldn't. These predate OpenPGP, and we just shouldn't worry
> about them at all. I want to remove all of those notes to start with.

Agreed, except I'd like to keep this one:

     * If an implementation is using zlib to interoperate with PGP 2.x,
       then the "windowBits" parameter should be set to -13.

I would also like to add an note about the cleartext signature
end-of-line differences in PGP.  The draft says (section 7.1):

   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end
   of any line is ignored when the cleartext signature is calculated.

PGP (all versions I've tested, including 8) does not ignore tabs at
the end of the line.

David

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: Hard expiration dates (was:I-DACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Date: Mon, 24 Mar 2003 17:59:47 -0500
Sender: [email-masked]

Thanks for the explanation.

Jon Callas wrote:
> Here's the central question: If Alice and Bob each have a key that by some
> coincidence share the same key material, should their keys have the same
> fingerprint?

It depends what you want the fingerprint to do.  If you want to use
the fingerprint to detect this specific sort of reuse, then you want
them to be the same.  If you want the fingerprint to be useful as a
unique index (up to breakage of the hash) for the key and its
signatures, and those signatures incorporate the non-MPI material,
then you want them to be different.  I think the latter is far more useful.

[Just so everyone's clear on the indexing problem, here's an example.
Alice creates a key with <time1,MPIs>, and gathers some signatures for
it.  Bob later creates a key with <time2,MPIs> and gathers his own
signatures.  Charlie receives both Alice's and Bob's keys.  Since they
have the same fingerprint, Charlie thinks they're the same, and merges
them together.  Whichever timestamp he keeps, Charlie will effectively
destroy the other key -- the signatures based on the key with the
other time won't verify.  This is very close to a real-world example:
Charlie is one of many keyservers that assume that fingerprints are
unique; Bob is created by an automated signing agent that (accidentally)
mangled Alice's timestamp.]

But, as I said before, if the point was to remove the creation time
from the key packet entirely (meaning that it wouldn't get hashed into
all signatures, either), then the fingerprint will serve both
purposes.  I'd be quite happy with that.  Was that the nature of the
proposal for a V5 format?

> None of the key management utilities give an easy interface to ask the
> question of whether two keys have the same key material by directly
> comparing them.

[Actually, GnuPG offers a switch to see the key material.  You might
argue that its interface isn't "easy", though. :-]

> Suppose Bob takes the key material from Alice's key, and makes a new key
> (which he doesn't have the private key to), and claims that one of Alice's
> signatures is actually his own. There is no easy way to figure out what's
> going on. If the fingerprints were the same, it'd be a snap.

I don't find this at all compelling.

First, if Bob wants to thwart this use of fingerprints, he simply
has to use the same creation time.  What does Bob gain by using
a different time in this attack?

Second, there *is* an easy way to figure out that Bob is bogus.  His
identity will have no valid self-signature; if you press him for one,
he can't produce it.  GnuPG, for one, rejects such things by default;
other tools *should* do the same (or at least note the impropriety loudly).
Alice *can* demonstrate a valid self-signature.  If your argument is that
Bob can pull this off by hiding Alice's key, then fingerprints won't
help, either.

Date: Mon, 24 Mar 2003 14:28:46 -0800
Subject: What's the consensus?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Here are some proposals for changes that I think are reasonable, based on
what I'm hearing here:

* IDEA gets marked as a MAY from a SHOULD. An implementation note gets put
in noting that it's patented, but used in PGP 2.

* We deprecate V3 keys. Specifically, we say {MUST|SHOULD} NOT be generated,
and {SHOULD|MAY} use. V3 signatures {MUST|SHOULD} not be generated. I lean
toward SHOULD rather than MUST, but that's only because I'm a gradualist. If
someone feels strongly that we should say MUST, just say so. Also, provide
comments on this.

* It sounds like the consensus on hard key expiration is that it needs to go
into a V5 format.

Other issues:

* There are a number of implementation notes that I believe are old enough
to go away. Given that RFCs, even if obsoleted, do not disappear, deleting
one is not a tragedy. I believe, for example, that anyone still using PGP
5.X really shouldn't. These predate OpenPGP, and we just shouldn't worry
about them at all. I want to remove all of those notes to start with.

* There may be similar text that can go away from the draft, as well.
Suggestions are welcome.

    Jon

Date: Mon, 24 Mar 2003 14:10:40 -0800
Subject: Re: Hard expiration dates (was: I-DACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
From: Jon Callas <[email-masked]>
To: Michael Young <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/24/03 9:07 AM, "Michael Young" <[email-masked]> wrote:

> Jon Callas noted:
>> The V4 fingerprint *includes* the creation time of the key, which is in most
>> people's opinion, a flaw.
> 
> Could you say why people thought this was a flaw?
> 

The reason is that if you have two keys that have the same key material,
they will have different fingerprints (unless they also have the same date).

People who believe this is a flaw think that the fingerprint should be a
function of the key material (and perhaps some other constants).

Here's the central question: If Alice and Bob each have a key that by some
coincidence share the same key material, should their keys have the same
fingerprint?

None of the key management utilities give an easy interface to ask the
question of whether two keys have the same key material by directly
comparing them.

Suppose Bob takes the key material from Alice's key, and makes a new key
(which he doesn't have the private key to), and claims that one of Alice's
signatures is actually his own. There is no easy way to figure out what's
going on. If the fingerprints were the same, it'd be a snap.

    Jon

Date: Mon, 24 Mar 2003 13:41:27 -0600
To: [email-masked] (Bodo Moeller)
From: Mike Markowitz <[email-masked]>
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Cc: [email-masked]
Sender: [email-masked]

At 02:07 AM 3/22/2003 +0100, Bodo Moeller wrote:

>... With my proposal, to set a "hard" expiration date,
>you include it in the certification self-signatures.  Thus an
>adversary who wants to remove the expiration date has to remove the
>self-signatures, rendering the key invalid (at least for software that
>rejects keys without self-signatures -- possibly this is a requirement
>that is missing in the specification, but this problem would affect V3
>keys as well).

I think *something* -- preferably along the lines of a "MUST" -- needs to be
added about software rejecting invalid keys.

PGP 8.0 has the following interesting "feature": if you simply render the
self-signature on a V4 key invalid (say by modifying the embedded hash value),
PGP8 *quietly* ignores that signature block (along with its expiration date)
when importing the key and allows it to be used like any other (unsigned) key.

So, if I create a key for myself with a fixed expiration date -- anticipating
the public revelation of my private key shortly after that date -- an attacker
can thwart my intentions by simply changing a single byte in the key. No PGP8
user would ever know the key had been tampered with... or that it was supposed
to expire. After all, the "fingerprint" on the key is still valid, so even 
if a
user checks it against the value published on my website, they'd never detect
the attack! (I don't think there is a solution, since the attacker can also
simply strip off the signature block. I guess I'm really complaining that
OpenPGP keys do not behave like X.509 certificates: if the signature block
contains a critical attribute like an expiration date, stripping it *should*
render the key invalid AND unusable... or at least generate a warning!)

In any case, since PGP8's strange behavior doesn't appear to violate anything
in the latest draft, I can't help feeling that 
draft-ietf-openpgp-rfc2440bis-07's
claim to "discuss implementation issues necessary to avoid security flaws" is
rather empty.

-mjm

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: Hard expiration dates (was: I-DACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Date: Mon, 24 Mar 2003 12:07:37 -0500
Sender: [email-masked]

Jon Callas noted:
> The V4 fingerprint *includes* the creation time of the key, which is in most
> people's opinion, a flaw.

Could you say why people thought this was a flaw?

I presume that everyone agreed that it must be included in the hashed
material for signatures.  Otherwise, the relative times in the various
subpackets would be meaningless.  (I think that using relative times
there was ill-advised anyway, but that's another matter.)  It would
make the time in the key packet completely worthless -- anyone could
change it arbitrarily without disturbing fingerprints or signatures.

If it were used in signatures but not fingerprints, this would leave us
with the same collating mess as we have for v3 keys.  The fingerprint
would not be sufficient as a unique key for indexing key material.
You'd have to tack on this other field, or compare the whole key, or
compute yet another strong hash.  I can't see how this is a feature
you'd want to retain from v3 :-(.

Now, if the argument was that the creation time didn't belong in the
key packet at all, I'd have to agree.

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shaw-openpgp-hkp-00.txt
Date: Mon, 24 Mar 2003 07:25:12 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: The OpenPGP HTTP Keyserver Protocol (HKP)
	Author(s)	: D. Shaw
	Filename	: draft-shaw-openpgp-hkp-00.txt
	Pages		: 8
	Date		: 2003-3-20
	
This document specifies a series of conventions to implement an
OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP).  As
this document is a codification and extension of a protocol that is
already in wide use, strict attention is paid to backward
compatibility with these existing implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shaw-openpgp-hkp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shaw-openpgp-hkp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shaw-openpgp-hkp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shaw-openpgp-hkp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-shaw-openpgp-hkp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 24 Mar 2003 11:56:40 +0100 (CET)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Sender: [email-masked]

David Shaw <[email-masked]>:
> On Sat, Mar 22, 2003 at 02:07:02AM +0100, Bodo Moeller wrote:
>> David Shaw <[email-masked]>:
>>> On Thu, Mar 06, 2003 at 03:53:30PM +0100, Bodo Moeller wrote:

>>>> What about appending a new section after 5.2.3.3 as follows to ensure
>>>> that there is a way to express key expiry such that keys cannot be
>>>> un-expired by attackers later [...]

>>> I've read all this, and I believe I understand what you are trying to
>>> do: get back the "hard" expiration date that v3 keys had, rather than
>>> the "soft" expiration date of v4 keys.  However, while the suggested
>>> fix results in something closer to a hard expiration date, it is not
>>> as hard as the original v3 expiration date since the expiration date
>>> still vulnerable to manipulation if an attacker can influence the key
>>> distribution channel.  [...]

>> Can you elaborate?  With my proposal, to set a "hard" expiration date,
>> you include it in the certification self-signatures.  Thus an
>> adversary who wants to remove the expiration date has to remove the
>> self-signatures, rendering the key invalid (at least for software that
>> rejects keys without self-signatures -- possibly this is a requirement
>> that is missing in the specification, but this problem would affect V3
>> keys as well).

> I think I wasn't clear enough.  An attacker that gets the secret key
> for an expired v3 key cannot un-expire that key without causing all of
> the certifications on this key to become invalid.  However, with your
> proposal for handling expiration on v4 keys, this same attacker - if
> she can control the key distribution channel - *can* perform this
> attack.  All she needs to do is issue a new certification
> self-signature without the key expiration subpacket, remove the old
> self-signature, and distribute this new key.

Er, yes, actually I am aware of this, I don't know what I was thinking
when I wrote my previous message.  -- The attacker could not actually
"un-expire" an expired key (because that key would not have any valid
certifications at all once it has expired assuming that all
certifications follow the suggested procedure); but if an attacker
obtains the secret key for a key that has not yet expired, he can
increase key lifetime beyond the intended expiry date by issuing new
self-signatures.  (In consequence, new certifications by others could
last longer than intended by the legitimate key owner.)  So while key
expiration would be final, expiration dates would not be as hard as
with the V3 format.

> I do agree that your proposal is "harder" than the current v4
> expiration system, but at the same time, it is not as hard as the v3
> system where any expiration tampering breaks every single
> certification.
> 
> This is why I was wondering why you didn't propose a v5 key that put a
> hard expiration date back into the key packet itself.  That is a truly
> hard expiration date as it cannot be tampered with even if the
> attacker can influence the key distribution channel.  Any tampering
> would break every certification on the key (whether self-sigs or
> otherwise).

I definitely would suggest to include provisions for hard expiration
dates in the V5 format when it is defined.  My proposal does not do
this because I wanted to show what can be done without redefining the
format in an incompatible way.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Sat, 22 Mar 2003 23:00:21 -0800
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
From: Jon Callas <[email-masked]>
To: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/22/03 4:23 AM, "Adrian 'Dagurashibanipal' von Bidder"
<[email-masked]> wrote:

> Not having read all the references, I could be wrong. But IIRC the
> really hard thing about v3 expiration date was that changing the
> expiration date would also change the key fingerprint (and keyid?). So,
> even when the adversary comes to possess the secret key he can't
> unexpire the key.

The V3 fingerprint is computed by the MD5 hash of the two RSA MPIs (sans
lengths). So no, it wouldn't change the fingerprint.

The V4 fingerprint *includes* the creation time of the key, which is in most
people's opinion, a flaw. We were considering a V5 format to change that at
one time.

    Jon

Date: Sat, 22 Mar 2003 11:17:31 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--0IvGJv3f9h+YhkrH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 22, 2003 at 01:23:15PM +0100, Adrian 'Dagurashibanipal' von Bid=
der wrote:
> On Sat, 2003-03-22 at 02:07, Bodo Moeller wrote:
>=20
> > > I've read all this, and I believe I understand what you are trying to
> > > do: get back the "hard" expiration date that v3 keys had, rather than
> > > the "soft" expiration date of v4 keys.  However, while the suggested
> > > fix results in something closer to a hard expiration date, it is not
> > > as hard as the original v3 expiration date since the expiration date
> > > still vulnerable to manipulation if an attacker can influence the key
> > > distribution channel.  [...]
> >=20
> > Can you elaborate?  With my proposal, to set a "hard" expiration date,
> > you include it in the certification self-signatures.  Thus an
> > adversary who wants to remove the expiration date has to remove the
> > self-signatures, rendering the key invalid (at least for software that
> > rejects keys without self-signatures -- possibly this is a requirement
> > that is missing in the specification, but this problem would affect V3
> > keys as well).
>=20
> Not having read all the references, I could be wrong. But IIRC the
> really hard thing about v3 expiration date was that changing the
> expiration date would also change the key fingerprint (and keyid?). So,
> even when the adversary comes to possess the secret key he can't
> unexpire the key.

V3 key fingerprints are calculated differently than v4, so the
V3 fingerprint would not change.  However, changing the expiration
date on a v3 key does change the hash of the key which causes all
certifications on the key to break.  A completely uncertified key is
of little use to an attacker.

David

--0IvGJv3f9h+YhkrH
Content-Type: application/pgp-signature
Content-Disposition: inline

--0IvGJv3f9h+YhkrH--

Date: Sat, 22 Mar 2003 11:15:44 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Mar 22, 2003 at 02:07:02AM +0100, Bodo Moeller wrote:
> 
> David Shaw <[email-masked]>:
> > On Thu, Mar 06, 2003 at 03:53:30PM +0100, Bodo Moeller wrote:
> 
> >> What about appending a new section after 5.2.3.3 as follows to ensure
> >> that there is a way to express key expiry such that keys cannot be
> >> un-expired by attackers later (see the threads at
> > >      http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
> >>      http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
> >>      http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
> >> and finally
> >>      http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html
> 
> > I've read all this, and I believe I understand what you are trying to
> > do: get back the "hard" expiration date that v3 keys had, rather than
> > the "soft" expiration date of v4 keys.  However, while the suggested
> > fix results in something closer to a hard expiration date, it is not
> > as hard as the original v3 expiration date since the expiration date
> > still vulnerable to manipulation if an attacker can influence the key
> > distribution channel.  [...]
> 
> Can you elaborate?  With my proposal, to set a "hard" expiration date,
> you include it in the certification self-signatures.  Thus an
> adversary who wants to remove the expiration date has to remove the
> self-signatures, rendering the key invalid (at least for software that
> rejects keys without self-signatures -- possibly this is a requirement
> that is missing in the specification, but this problem would affect V3
> keys as well).

I think I wasn't clear enough.  An attacker that gets the secret key
for an expired v3 key cannot un-expire that key without causing all of
the certifications on this key to become invalid.  However, with your
proposal for handling expiration on v4 keys, this same attacker - if
she can control the key distribution channel - *can* perform this
attack.  All she needs to do is issue a new certification
self-signature without the key expiration subpacket, remove the old
self-signature, and distribute this new key.

I do agree that your proposal is "harder" than the current v4
expiration system, but at the same time, it is not as hard as the v3
system where any expiration tampering breaks every single
certification.

This is why I was wondering why you didn't propose a v5 key that put a
hard expiration date back into the key packet itself.  That is a truly
hard expiration date as it cannot be tampered with even if the
attacker can influence the key distribution channel.  Any tampering
would break every certification on the key (whether self-sigs or
otherwise).

David

Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Organization: 
Date: 22 Mar 2003 13:23:15 +0100
Sender: [email-masked]

--=-Vtm3MoPh6MX3N4mVX0hM
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2003-03-22 at 02:07, Bodo Moeller wrote:

> > I've read all this, and I believe I understand what you are trying to
> > do: get back the "hard" expiration date that v3 keys had, rather than
> > the "soft" expiration date of v4 keys.  However, while the suggested
> > fix results in something closer to a hard expiration date, it is not
> > as hard as the original v3 expiration date since the expiration date
> > still vulnerable to manipulation if an attacker can influence the key
> > distribution channel.  [...]
>=20
> Can you elaborate?  With my proposal, to set a "hard" expiration date,
> you include it in the certification self-signatures.  Thus an
> adversary who wants to remove the expiration date has to remove the
> self-signatures, rendering the key invalid (at least for software that
> rejects keys without self-signatures -- possibly this is a requirement
> that is missing in the specification, but this problem would affect V3
> keys as well).

Not having read all the references, I could be wrong. But IIRC the
really hard thing about v3 expiration date was that changing the
expiration date would also change the key fingerprint (and keyid?). So,
even when the adversary comes to possess the secret key he can't
unexpire the key.

cheers
-- vbi

--=20
NOTE: my email addresses in usenet postings change frequently!

--=-Vtm3MoPh6MX3N4mVX0hM
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Signature policy: http://fortytwo.ch/legal/gpg/email.20020822?version=1.3&md5sum=14ca616f14682a82cb9cc25c9b34a10d

--=-Vtm3MoPh6MX3N4mVX0hM--

Date: Sat, 22 Mar 2003 02:07:02 +0100 (CET)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Sender: [email-masked]

David Shaw <[email-masked]>:
> On Thu, Mar 06, 2003 at 03:53:30PM +0100, Bodo Moeller wrote:

>> What about appending a new section after 5.2.3.3 as follows to ensure
>> that there is a way to express key expiry such that keys cannot be
>> un-expired by attackers later (see the threads at
> >      http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
>>      http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
>>      http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
>> and finally
>>      http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html

> I've read all this, and I believe I understand what you are trying to
> do: get back the "hard" expiration date that v3 keys had, rather than
> the "soft" expiration date of v4 keys.  However, while the suggested
> fix results in something closer to a hard expiration date, it is not
> as hard as the original v3 expiration date since the expiration date
> still vulnerable to manipulation if an attacker can influence the key
> distribution channel.  [...]

Can you elaborate?  With my proposal, to set a "hard" expiration date,
you include it in the certification self-signatures.  Thus an
adversary who wants to remove the expiration date has to remove the
self-signatures, rendering the key invalid (at least for software that
rejects keys without self-signatures -- possibly this is a requirement
that is missing in the specification, but this problem would affect V3
keys as well).

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Fri, 21 Mar 2003 19:14:54 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Hard expiration dates (was: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Mar 06, 2003 at 03:53:30PM +0100, Bodo Moeller wrote:

> What about appending a new section after 5.2.3.3 as follows to ensure
> that there is a way to express key expiry such that keys cannot be
> un-expired by attackers later (see the threads at
>      http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
>      http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
>      http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
> and finally
>      http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html

I've read all this, and I believe I understand what you are trying to
do: get back the "hard" expiration date that v3 keys had, rather than
the "soft" expiration date of v4 keys.  However, while the suggested
fix results in something closer to a hard expiration date, it is not
as hard as the original v3 expiration date since the expiration date
still vulnerable to manipulation if an attacker can influence the key
distribution channel.  This attack is not possible with the v3
expiration system.

I'm not proposing this as something for 2440bis, but I'm curious why
you aren't proposing a v5 key format with the expiration date in the
key packet as it was in v3 keys?  This would seem to give the best of
all worlds - the "hard" expiration date in the key packet is truly
hard, and if the hard expiration date is not used, then the same
"soft" expiration date from the self-signature that is in use now can
be used.  (Incidentally, this is how GnuPG handles expiration on v3
keys with v4 self-sigs.)

Whether the direct-key signature solution or the v5 key solution is
used, it will take some new code written and released to handle it, so
why not use the more rigorous solution?

Again, I'm not suggesting v5 keys for 2440bis.  I'm sure there are
other things that people would want for a v5 key format aside from
hard expiration dates.

David

Date: Fri, 21 Mar 2003 11:58:23 -0600
To: pplf <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: Re: OpenPGP.org and GnuPG
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 12:20 PM 3/19/2003 +0100, pplf wrote:
>Do you think it is a good thing that GnuPG is not shown in the 
>www.openpgp.org "Download" page ?

Now that *that* has been corrected, it might be worth pointing out to Phil
that RFC2440 is NOT an IETF "Standard" so that he can correct that error
(which appears on numerous pages throughout the site).

For example, http://www.openpgp.org/about_openpgp/ says:
"By becoming an IETF standard (<http://www.ietf.org/rfc/rfc2440.txt>RFC 
2440), OpenPGP ..."

while http://www.openpgp.org/technical/ says:
"The OpenPGP standard is defined by the OpenPGP Working Group of the Internet
Engineering Task Force (<http://www.ietf.org/>IETF) standard 
<http://www.ietf.org/rfc/rfc2440.txt>RFC 2440."

Perhaps Phil needs to read http://www.ietf.org/rfc/rfc2026.txt so that the 
subtle
difference in meaning between "RFC" and a "IETF Standard" is more clear. Or 
is he
using "standard," as opposed to "Standard," as a synonym for "Proposed 
Standard?"
It's hard to tell. <g>)

"Standards" are the RFCs listed in the the *first* table on
http://www.rfc-editor.org/rfcxx00.html, not just anything that appears on
that page.

Good luck!

-mjm

==========
Michael J. Markowitz, Ph.D.        Email: [email-masked]
Vice President R&D                 Voice: 708-445-1704 (Oak Park)
Information Security Corporation          847-405-0500 (Deerfield)
1011 Lake Street, Suite 212        Fax:   708-445-9705
Oak Park, IL  60301                WWW:   http://www.infoseccorp.com    

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Curiosity: use of deviant old-style headers in hash material
Date: Fri, 21 Mar 2003 11:52:26 -0500
Sender: [email-masked]

David's requests for clarifications leads me to ask a historical
question... why were the constants in the hash material chosen to be
the old-style packet headers with length-of-length set inconsistently
with their use here?  In the following excerpt, the natural
length-of-length would be 2 (4-byte length to follow) rather than 0
(1-byte length to follow).  Was this a mistake, an intentional
deviation to prevent some perceived attack, a strange artifact of the
PGP5 implementation, or something else?  (This is just a curiosity,
not a request that it be documented.)

>    without any header. A V4 certification hashes the constant 0xb4 for
>    user ID certifications or the constant 0xd1 for User Attribute
>    certifications (which are old-style packet headers with the
>    length-of-length set to zero), followed by a four-octet number

Date: Thu, 20 Mar 2003 10:19:38 -0800
Subject: Re: Minor clarification for fingerprint calculation
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/7/03 7:17 PM, "David Shaw" <[email-masked]> wrote:

> I believe this line would be better as:
> 
>  A V4 fingerprint is the 160-bit SHA-1 hash of the octet
>  0x99... (etc)

Done.

    Jon

Date: Thu, 20 Mar 2003 12:26:48 +0100
From: pplf <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP.org and GnuPG
Sender: [email-masked]

pplf wrote:
> The web site www.openpgp.org has no link at all for GnuPG versions on 
> his page download : http://www.openpgp.org/resources/downloads.shtml

The problem is fixed. See below :

-------- Original Message --------
Subject: Re: GnuPG and the OpenPGP.org web site
Date: Wed, 19 Mar 2003 19:12:25 -0800
From: Philip Zimmermann <[email-masked]>
To: Anthony E. Greene <[email-masked]>
CC: [email-masked], [email-masked]

I just updated the download section of the openpgp.org web site.  It
had not been updated for about two years.  It really needs more links
for more source code.  If anyone wants to send me info about other
products or projects in the openpgp arena, I could use the help.  -prz

On Wednesday, Mar 19, 2003, at 05:36 US/Pacific, Anthony E. Greene
wrote:

 > Mr. Zimmermann,
 >
 > I have been a PGP user and privacy advocate for years. I am bothered by
 > the omission of a link to GnuPG on the Download page of the OpenPGP.org
 > web site.  GnuPG is the second most widely used OpenPGP application,
 > and
 > the only one that ships with an operating system (actually, I believe
 > it
 > ships with more than one OS). There are email clients that are designed
 > specifically to include support for GnuPG. GnuPG, as implied by it's
 > name,
 > is part of the GNU Project, and is not going to go away anytime soon.
 >
 > The omission of GnuPG may indeed be a simple human omission on an old
 > seldom-updated site, but the situation has endured for too long. The
 > omission now appears to be deliberate, whatever the truth may be.
 >
 > GnuPG is significant. There should be a link to it on the Download
 > page of
 > the OpenPGP web site.
 >
 > --
 > Anthony E. Greene
 > <mailto:[email-masked]%3E>
 > OpenPGP Key: 0x6C94239D/7B3D BD7D 7D91 1B44 BA26  C484 A42A 60DD 6C94
 > 239D
 > AOL/Yahoo Messenger: TonyG05    HomePage:
 > <http://www.pobox.com/~agreene/>
 > Linux. The choice of a GNU generation <http://www.linux.org/>
 >

----------------------------------------------
Philip R Zimmermann        [email-masked]
http://philzimmermann.com  tel +1 650 322-7377
(spelled with 2 n's)       fax +1 650 322-7877

_______________________________________________
Gnupg-users mailing list
[email-masked]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
pplf - French OpenPGP page    <[email-masked]>
"OpenPGP en francais"         PGP: 8263 8399 2074 5277 a6d3
http://www.openpgp.fr.st           622d 1b66 ea3d caa0 8c94

To: pplf <[email-masked]>
Cc: [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP.org and GnuPG
Date: 19 Mar 2003 19:52:35 -0500
Lines: 65
Sender: [email-masked]

No, openpgp.org is not related to the OpenPGP IETF Working Group.

-derek

pplf <[email-masked]> writes:

> Hello,
> 
> The web site www.openpgp.org has no link at all for GnuPG versions on
> his page download : http://www.openpgp.org/resources/downloads.shtml
> 
> The links given to download OpenPGP are the pgp.com, pgpi.com, or
> web.mit.edu/network/pgp links.
> 
> The name "GnuPG" or GPG appears only at the "Members" page.
> 
> I think it is not a good thing : GnuPG is the most famous free OpenPGP
> version and it must be here.
> 
> Last week, I had a discussion by e-mail with Philip Zimmermann, and I
> said him some people may think he is misappropriating the name
> "OpenPGP.org", and that he done this because he sells PGP(tm)
> www.pgp.com and FileCrypt www.veridis.com/openpgp/
> 
> Philip Zimmermann replied me that the "Download" page at the
> openpgp.org web site was not updated since his beginning (2 or 3 years
> ago, I think), then he said me in another e-mail that I was
> "insulting" him.
> 
> Unfortunately, he didn't changed the "Download" page at
> www.openpgp.org and GnuPG is still not there :-(
> 
> Do you think it is a good thing that GnuPG is not shown in the
> www.openpgp.org "Download" page ?
> 
> I see by doing a whois that the domain "openpgp.org" is owned by the
> "OpenPGP Research Group".
> 
> domain:		OPENPGP.ORG
> owner-address:	OpenPGP Research Group
> owner-address:	C/O Terje Elde
> owner-address:	C/O Jan Pedersen
> owner-address:	Granliveien 1
> owner-address:	N-1406
> owner-address:	Ski
> owner-address:	Norway
> 
> Do you know if this "OpenPGP Research Group" part of the IETF-OpenPGP
> working group ?
> 
> Thanks,
> 
> pplf
> 
> 
> -- 
> pplf - French OpenPGP page    <[email-masked]>
> "OpenPGP en francais"         PGP: 8263 8399 2074 5277 a6d3
> http://www.openpgp.fr.st           622d 1b66 ea3d caa0 8c94
> 

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

Date: Wed, 19 Mar 2003 12:20:51 +0100
From: pplf <[email-masked]>
To: [email-masked], [email-masked]
Subject: OpenPGP.org and GnuPG
Sender: [email-masked]

Hello,

The web site www.openpgp.org has no link at all for GnuPG versions on 
his page download : http://www.openpgp.org/resources/downloads.shtml

The links given to download OpenPGP are the pgp.com, pgpi.com, or 
web.mit.edu/network/pgp links.

The name "GnuPG" or GPG appears only at the "Members" page.

I think it is not a good thing : GnuPG is the most famous free OpenPGP 
version and it must be here.

Last week, I had a discussion by e-mail with Philip Zimmermann, and I 
said him some people may think he is misappropriating the name 
"OpenPGP.org", and that he done this because he sells PGP(tm) 
www.pgp.com and FileCrypt www.veridis.com/openpgp/

Philip Zimmermann replied me that the "Download" page at the openpgp.org 
web site was not updated since his beginning (2 or 3 years ago, I 
think), then he said me in another e-mail that I was "insulting" him.

Unfortunately, he didn't changed the "Download" page at www.openpgp.org 
and GnuPG is still not there :-(

Do you think it is a good thing that GnuPG is not shown in the 
www.openpgp.org "Download" page ?

I see by doing a whois that the domain "openpgp.org" is owned by the 
"OpenPGP Research Group".

domain:		OPENPGP.ORG
owner-address:	OpenPGP Research Group
owner-address:	C/O Terje Elde
owner-address:	C/O Jan Pedersen
owner-address:	Granliveien 1
owner-address:	N-1406
owner-address:	Ski
owner-address:	Norway

Do you know if this "OpenPGP Research Group" part of the IETF-OpenPGP 
working group ?

Thanks,

pplf

-- 
pplf - French OpenPGP page    <[email-masked]>
"OpenPGP en francais"         PGP: 8263 8399 2074 5277 a6d3
http://www.openpgp.fr.st           622d 1b66 ea3d caa0 8c94

Date: Tue, 18 Mar 2003 00:40:21 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jon Callas <[email-masked]> writes:
>On 3/11/03 9:28 AM, "Mike Markowitz" <[email-masked]> wrote:
>
>[Incidentally, what we're talking about is PGP's importing X.509
>certificates. It imports them as V3 keys. This is a meta-2440 issue, which
>is why I never brought it up.]
>
>[...]
>
>>Any chance this will be corrected in PGP8 the near future? (Converting
>>a cert into a V4 key with appropriate algorithm preferences is not that hard.)
>
>Personally, I think this is a misfeature. However, I *understand* why it was
>done that way. There are a whole host of little fiddly things about making
>one into a V4 key that can be completely sidestepped by making it a V3.

I've been using X.509 keys as v4 keys for PGP for ages without any problems.
You just format the key in the PGP manner and use the validity from the
cert to provide the date for the hashed key ID.

>There are so many of them that making it into a V4 key could be called "a
>can of worms." Certainly, it would require a couple of design meetings.
>(Example worm coming out of the can -- what if the X.509 cert has in its
>basic constraints that it's an encryption-only key? 2440 says that a
>top-level key must be capable of signing. Possible solutions include
>ignoring the issue, and making that key a sub-key while generating a new
>top-level key.)

I don't try and make the X.509-derived keys *that* PGP-ish.  It works fine
without going to that level, which sidesteps the whole issue.

Peter.

Date: Mon, 17 Mar 2003 11:39:12 +0100
From: Bodo Moeller <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, Jason Harris <[email-masked]>, Len Sassaman <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, [email-masked], [email-masked]
Subject: Re: v4-only keyanalyze
Sender: [email-masked]

On Mon, Mar 17, 2003 at 01:23:37AM -0800, Jon Callas wrote:

> [...]         Older keys are more likely to have become compromised. [...]

> I'll bet that if you look at the most connected V3 keys, you'll find few if
> any of them less than a year old. Even less than two years old. An analysis
> of "reachability" that does not consider key age at all is flawed, unless
> you subscribe to the radical notion that the age of keys doesn't matter.

So as key expiry does not really work, now we are expiring key data
formats instead? :-)

[I haven't seen any replies to my recent proposal
     http://www.imc.org/ietf-openpgp/mail-archive/msg04950.html
which should finally solve that issue ...]

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Mon, 17 Mar 2003 01:23:37 -0800
Subject: Re: v4-only keyanalyze
From: Jon Callas <[email-masked]>
To: Werner Koch <[email-masked]>, Jason Harris <[email-masked]>
CC: Len Sassaman <[email-masked]>, Bodo Moeller <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/16/03 6:51 AM, "Werner Koch" <[email-masked]> wrote:

> 
> On Sat, 15 Mar 2003 18:57:14 -0500, Jason Harris said:
> 
>> Summary:  strong and reachable set sizes are reduced by about 50%.
> 
> Frankly, I expected such a result.  So we have a good reason not to
> deprecate v3 keys used for key signature.  "an existing v3 key MAY be
> used for key certification" sounds reasonable.

Again -- I want to say more about what "deprecate" means. It does *not* mean
to get rid of things. It means, in plain words, "Don't do this any more,
because it's going away."

Deprecating V3 keys would mean something like saying that they ought not (I
pick that because I don't want to presume a SHOULD or MUST) be created. One
ought not make any *new* ones.

It could also mean that we would say that existing V3 keys ought not certify
keys -- or that such certifications ought to be V4. There's nothing wrong
with making a V4 signature with a V3 key, don't you know.

I think it is far more significant that 91% of all keys are V4. This tells
me that we can safely deprecate V3.

It is my opinion that any information about "set sizes" is a canard for
several reasons.

* Since no one is saying that deprecating means eliminating said keys, this
is a straw man argument.

* OpenPGP does not specify a trust model, and "reachability" is not even
part of the traditional PGP Web of Trust. Such discussions are
extra-OpenPGP.

* This does not take into account another factor -- that of the "security"
of the keys. This is also one of the things that is beyond OpenPGP and even
any discussion of public key cryptography.

There's a paradox we deal with. On the one hand, the most secure keys are
the new ones. Older keys are more likely to have become compromised. On the
other hand, older keys are the ones that are more connected. They have to
be.

I'll bet that if you look at the most connected V3 keys, you'll find few if
any of them less than a year old. Even less than two years old. An analysis
of "reachability" that does not consider key age at all is flawed, unless
you subscribe to the radical notion that the age of keys doesn't matter.
(Now, to be fair, I have in the past argued this notion myself, but I know
I'm being a radical when I do that.)

However, that's not germane to this discussion. Let me repeat myself.
Deprecating V3 keys does not mean saying existing keys should be immediately
swept away. Eventually, sure. But I'd say that the date at which we should
declare existing V3 keys to be no longer viable should be *after* a
reasonable lifespan of a key.

    Jon

To: Jason Harris <[email-masked]>
Cc: Len Sassaman <[email-masked]>, Bodo Moeller <[email-masked]>, Jon Callas <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, [email-masked], [email-masked]
Subject: Re: v4-only keyanalyze
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sun, 16 Mar 2003 15:51:49 +0100
Sender: [email-masked]

On Sat, 15 Mar 2003 18:57:14 -0500, Jason Harris said:

> Summary:  strong and reachable set sizes are reduced by about 50%.

Frankly, I expected such a result.  So we have a good reason not to
deprecate v3 keys used for key signature.  "an existing v3 key MAY be
used for key certification" sounds reasonable.

Many thanks for running this analyze job, Jason.

Salam-Shalom,

   Werner

Date: Sat, 15 Mar 2003 18:57:14 -0500
From: Jason Harris <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Bodo Moeller <[email-masked]>, Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, [email-masked], [email-masked], Jason Harris <[email-masked]>
Subject: v4-only keyanalyze (was Re: meeting in San Francisco?)
Sender: [email-masked]

--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 07, 2003 at 11:24:21AM -0800, Len Sassaman wrote:

> I do not think the web of trust would be significantly altered if V3 keys
> were depricated. (I'd like to see Drew Streib's key analysis run with the
> v3 keys excluded to test this theory). More important to the users is
> individual trust changes. Perhaps this could be addressed by stating that
> key certifications "MAY" but "SHOULD NOT" be v3 format (and reference RFC
> 1991)? (Am I correct in assuming that v3 as described in OpenPGP is
> identical to v3 in 1991?)
>=20
> I'd also be happy just cutting the v3 web loose.

A v4-only analysis, otherwise using the same data as the full analysis
for the same date, is at:

  http://keyserver.kjsl.com/~jharris/ka/2003-03-09-v4only/

Summary:  strong and reachable set sizes are reduced by about 50%.

Of 1,829,065 keys, 1,662,070 are v4, ~91%.

--=20
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[email-masked] | web:  http://jharris.cjb.net/

--7AUc2qLy4jB3hD7Z
Content-Type: application/pgp-signature
Content-Disposition: inline

--7AUc2qLy4jB3hD7Z--

Date: Fri, 14 Mar 2003 22:13:04 -0800
Subject: Re: Subpacket clarification
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>
CC: "Jeroen C. van Gelderen" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/14/03 5:39 PM, "David Shaw" <[email-masked]> wrote:

>> The subpacket areas are intended to be unordered. I think specifying
>> ordering is a bad idea, as you have to solve the general case, anyway.
>> OpenPGP needs simplification, not more arcane rules.
> 
> I'd be quite content to see that sentence go away altogether.

It's gone.

    Jon

Date: Fri, 14 Mar 2003 20:39:37 -0500
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: "Jeroen C. van Gelderen" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Subpacket clarification
Mail-Followup-To: Jon Callas <[email-masked]>, "Jeroen C. van Gelderen" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Fri, Mar 14, 2003 at 11:29:40AM -0800, Jon Callas wrote:
> 
> On 3/13/03 11:15 AM, "David Shaw" <[email-masked]> wrote:
> > 
> > On Thu, Mar 13, 2003 at 12:25:12AM -0500, Jeroen C. van Gelderen wrote:
> >> 
> >> 
> >> On Wednesday, Mar 12, 2003, at 22:14 US/Eastern, David Shaw wrote:
> >>> In section 5.2.4.1. Subpacket Hints:
> >>> 
> >>>   An implementation SHOULD put the two mandatory subpackets, creation
> >>>   time and issuer, as the first subpackets in the subpacket list,
> >>>   simply to make it easier for the implementer to find them.
> >>> 
> >>> Both PGP and GnuPG put the creation time in the hashed area, and the
> >>> issuer in the unhashed area, and the most recent draft was revised to
> >>> match this reality.  Given that, perhaps it would be good to modify
> >>> the phrase slightly with "... as the first subpackets in their
> >>> respective subpacket lists..."
> >> 
> >> Just so I understand... given that a valid OpenPGP message can have
> >> these packets anywhere in the list, how is it easier for a conformant
> >> implementation to find them? Faster... now that I could understand. But
> >> it would seem that any valid OpenPGP implementation will have to
> >> implement the complete locating algorithm anyway. What is it that I'm
> >> missing?
> 
> 
> The subpacket areas are intended to be unordered. I think specifying
> ordering is a bad idea, as you have to solve the general case, anyway.
> OpenPGP needs simplification, not more arcane rules.

I'd be quite content to see that sentence go away altogether.

David

Date: Fri, 14 Mar 2003 11:29:40 -0800
Subject: Re: Subpacket clarification
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, "Jeroen C. van Gelderen" <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/13/03 11:15 AM, "David Shaw" <[email-masked]> wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, Mar 13, 2003 at 12:25:12AM -0500, Jeroen C. van Gelderen wrote:
>> 
>> 
>> On Wednesday, Mar 12, 2003, at 22:14 US/Eastern, David Shaw wrote:
>>> In section 5.2.4.1. Subpacket Hints:
>>> 
>>>   An implementation SHOULD put the two mandatory subpackets, creation
>>>   time and issuer, as the first subpackets in the subpacket list,
>>>   simply to make it easier for the implementer to find them.
>>> 
>>> Both PGP and GnuPG put the creation time in the hashed area, and the
>>> issuer in the unhashed area, and the most recent draft was revised to
>>> match this reality.  Given that, perhaps it would be good to modify
>>> the phrase slightly with "... as the first subpackets in their
>>> respective subpacket lists..."
>> 
>> Just so I understand... given that a valid OpenPGP message can have
>> these packets anywhere in the list, how is it easier for a conformant
>> implementation to find them? Faster... now that I could understand. But
>> it would seem that any valid OpenPGP implementation will have to
>> implement the complete locating algorithm anyway. What is it that I'm
>> missing?

The subpacket areas are intended to be unordered. I think specifying
ordering is a bad idea, as you have to solve the general case, anyway.
OpenPGP needs simplification, not more arcane rules.

    Jon

Date: Thu, 13 Mar 2003 16:47:28 -0500
Subject: Re: Subpacket clarification
Cc: [email-masked]
To: David Shaw <[email-masked]>
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Thursday, Mar 13, 2003, at 14:15 US/Eastern, David Shaw wrote:
>>>   An implementation SHOULD put the two mandatory subpackets, creation
>>>   time and issuer, as the first subpackets in the subpacket list,
>>>   simply to make it easier for the implementer to find them.
>
> I've always interpreted "easier" as "faster" in that sentence.

Thanks. It might be good to explicitly say so. In fact, "easier for the 
implementor" cannot logically apply to the resource requirements of a 
run. The implementor has to do a fixed amount of work to implement the 
complete and correct algorithm, regardless of where the packets are 
generally placed.

You could say "easier for the implementation" of course:

   An implementation SHOULD put the two mandatory subpackets, creation
   time and issuer, as the first subpackets in the subpacket list,
   simply to make it easier for the implementation to find them.

This is still easy to misread for those not-so-well-versed in English. 
How about:

   An implementation SHOULD put the two mandatory subpackets, creation
   time and issuer, as the first subpackets in the subpacket list,
   simply to make it less costly -on average- for the implementation
   to find them.

Now come up with some better wording...

Cheers,
-J
-- 
Jeroen C. van Gelderen - [email-masked]

"They accused us of suppressing freedom of expression.
This was a lie and we could not let them publish it."
   -- Nelba Blandon,
      Nicaraguan Interior Ministry Director of Censorship

Date: Thu, 13 Mar 2003 14:15:13 -0500
From: David Shaw <[email-masked]>
To: "Jeroen C. van Gelderen" <[email-masked]>
Cc: [email-masked]
Subject: Re: Subpacket clarification
Mail-Followup-To: "Jeroen C. van Gelderen" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Mar 13, 2003 at 12:25:12AM -0500, Jeroen C. van Gelderen wrote:
> 
> 
> On Wednesday, Mar 12, 2003, at 22:14 US/Eastern, David Shaw wrote:
> >In section 5.2.4.1. Subpacket Hints:
> >
> >   An implementation SHOULD put the two mandatory subpackets, creation
> >   time and issuer, as the first subpackets in the subpacket list,
> >   simply to make it easier for the implementer to find them.
> >
> >Both PGP and GnuPG put the creation time in the hashed area, and the
> >issuer in the unhashed area, and the most recent draft was revised to
> >match this reality.  Given that, perhaps it would be good to modify
> >the phrase slightly with "... as the first subpackets in their
> >respective subpacket lists..."
> 
> Just so I understand... given that a valid OpenPGP message can have 
> these packets anywhere in the list, how is it easier for a conformant 
> implementation to find them? Faster... now that I could understand. But 
> it would seem that any valid OpenPGP implementation will have to 
> implement the complete locating algorithm anyway. What is it that I'm 
> missing?

I've always interpreted "easier" as "faster" in that sentence.

David

Date: Thu, 13 Mar 2003 00:25:12 -0500
Subject: Re: Subpacket clarification
Cc: [email-masked]
To: David Shaw <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Wednesday, Mar 12, 2003, at 22:14 US/Eastern, David Shaw wrote:
> In section 5.2.4.1. Subpacket Hints:
>
>    An implementation SHOULD put the two mandatory subpackets, creation
>    time and issuer, as the first subpackets in the subpacket list,
>    simply to make it easier for the implementer to find them.
>
> Both PGP and GnuPG put the creation time in the hashed area, and the
> issuer in the unhashed area, and the most recent draft was revised to
> match this reality.  Given that, perhaps it would be good to modify
> the phrase slightly with "... as the first subpackets in their
> respective subpacket lists..."

Just so I understand... given that a valid OpenPGP message can have 
these packets anywhere in the list, how is it easier for a conformant 
implementation to find them? Faster... now that I could understand. But 
it would seem that any valid OpenPGP implementation will have to 
implement the complete locating algorithm anyway. What is it that I'm 
missing?

Cheers,
-J

-- 
"They accused us of suppressing freedom of expression.
This was a lie and we could not let them publish it."
-- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship

Date: Wed, 12 Mar 2003 22:37:21 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Finalizing notary signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I'd like to start some discussion so we can finish the specification
of notary signatures.  There are still some missing pieces.

To recap, the notary signature is a signature on a signature, as if
made by a notary.  The notary should not need the original document,
the public key of the signer, or anything other than the signature
packet to issue the notary signature.

In <http://www.imc.org/ietf-openpgp/mail-archive/msg03987.html> Hal
Finney suggested a rule to canonicalize a signature packet so it can
be hashed and signed.  Paraphrased into RFC language, that is:

  When a signature is made over a signature, the hash data starts with
  the octet 0x88, followed by the four-octet length of the signature,
  and then the body of the signature packet.  (Note that this is an
  old-style packet header for a signature packet with the
  length-of-length set to zero).

I believe section 5.2.4. (Computing Signatures), would be the best
place for this.

David

Date: Wed, 12 Mar 2003 22:14:35 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Subpacket clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In section 5.2.4.1. Subpacket Hints:

   An implementation SHOULD put the two mandatory subpackets, creation
   time and issuer, as the first subpackets in the subpacket list,
   simply to make it easier for the implementer to find them.

Both PGP and GnuPG put the creation time in the hashed area, and the
issuer in the unhashed area, and the most recent draft was revised to
match this reality.  Given that, perhaps it would be good to modify
the phrase slightly with "... as the first subpackets in their
respective subpacket lists..."

David

From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Further deprecating PGP2
Date: Wed, 12 Mar 2003 16:37:56 -0500
Sender: [email-masked]

On Wednesday 12 March 2003 07:25, Jon Callas wrote:

> This is on the list of things to improve someday. Remember, though, that
> every day an engineer is working on Feature X, they are not working on
> Feature Y. If V3 keys are deprecated, it moves up in priority list.

This is indeed the crux of the issue.

Everyday that OpenPGP implementors
are working to add crufty old versions,
they are not adding new, useful and
current code.

Implementors are free - and many do -
to add pgp2.6 features to their products.

But, that's the implentation of a product,
not the standard known as OpenPGP.

It's a market decision;  and it would seem
that for as many implementations out
there that have a need for pgp2.6, there
are those that have no need for pgp2.6.

There was once a view that for OpenPGP
to succeed, it would need to embrace the
old pgp2.6 stuff.  That was shown to not
be reality when most users switched to
the newer formats, far faster than many
expected.

There are few pgp2.6 users left (those
that use it on a regular basis, as opposed
to people with old messages encrypted
in old formats) and there are even fewer
of those that need a single client that
compatibly switches between the two.

There is no reason, AFAICS, to even
mention pgp2.6 versions within the
OpenPGP central standard.  Its place
might be in an appendix or the like,
describing how it is done, for those
who wish.

The overriding need for OpenPGP is
not to deal with old formats, but to
reduce the variants and complexity.

A simpler more solid standard will
result in more support; a more complex,
finicky, exceptions-laden monstrosity
will result in fragmentation and
uncertain growth as the big code
bases struggle to stretch into new
areas.

Deprecating v3 keys within the
standard does not need to mean that
an implementation MUST NOT support
those keys.  Deprecation can just
define what it means to be OpenPGP.

-- 
iang

Date: Wed, 12 Mar 2003 16:18:49 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Dash escaping consensus?
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Wed, Mar 12, 2003 at 11:50:27AM +0000, Matthew Byng-Maddick wrote:
> 
> On Tue, Mar 11, 2003 at 02:42:42PM -0800, Jon Callas wrote:
> > What's the consensus? Any line may be dash-escaped, or only "From "? I wrote
> > it the first way, changed it to the second, and it seems we're back to the
> > first.
> 
> My instinctive reaction on this is that ``An implementation MAY dash escape
> any line, SHOULD dash escape lines commencing "From", and MUST dash escape
> any line commencing in a dash.''

I'm okay with this wording.  It helps point out the "From " issue.

David

To: OpenPGP <[email-masked]>
Subject: Re: Dash escaping consensus?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 12 Mar 2003 18:25:27 +0100
Sender: [email-masked]

On Tue, 11 Mar 2003 14:42:42 -0800, Jon Callas said:

> What's the consensus? Any line may be dash-escaped, or only "From "? I wrote
> it the first way, changed it to the second, and it seems we're back to the
> first.

I'd say, the first.  Matthew Byng-Maddick wording would be okay too.

Shalom-Salam,

   Werner

Date: Wed, 12 Mar 2003 10:31:07 -0500
Subject: Re: Dash escaping consensus?
Cc: OpenPGP <[email-masked]>
To: Matthew Byng-Maddick <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Wednesday, Mar 12, 2003, at 06:50 US/Eastern, Matthew Byng-Maddick 
wrote:

>
> On Tue, Mar 11, 2003 at 02:42:42PM -0800, Jon Callas wrote:
>> What's the consensus? Any line may be dash-escaped, or only "From "? 
>> I wrote
>> it the first way, changed it to the second, and it seems we're back 
>> to the
>> first.
>
> My instinctive reaction on this is that ``An implementation MAY dash 
> escape
> any line, SHOULD dash escape lines commencing "From", and MUST dash 
> escape
> any line commencing in a dash.''
>
> This would make it nice and unambiguous, IMO.
>
> Also ``An implementation MUST strip the string "- " if it occurs at the
> beginning of a line, and SHOULD warn on "-" and any character other 
> than
> a space at the beginning of a line.''

Seconded.

-J

Date: Wed, 12 Mar 2003 04:25:39 -0800
Subject: Re: Further deprecating PGP2
From: Jon Callas <[email-masked]>
To: Mike Markowitz <[email-masked]>
CC: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/11/03 9:28 AM, "Mike Markowitz" <[email-masked]> wrote:

[Incidentally, what we're talking about is PGP's importing X.509
certificates. It imports them as V3 keys. This is a meta-2440 issue, which
is why I never brought it up.]

> Importing an RSA certificate as a V3 key doesn't exactly sound like
> deprecation
> to me. 

Well, that depends entirely on your opinion of X.509, doesn't it? :-)

No, but humorously, folks, that's the main reason I said "effectively" --
it's the glaring exception.

>Any chance this will be corrected in PGP8 the near future? (Converting
> a cert into a V4 key with appropriate algorithm preferences is not that hard.)

Personally, I think this is a misfeature. However, I *understand* why it was
done that way. There are a whole host of little fiddly things about making
one into a V4 key that can be completely sidestepped by making it a V3.
There are so many of them that making it into a V4 key could be called "a
can of worms." Certainly, it would require a couple of design meetings.
(Example worm coming out of the can -- what if the X.509 cert has in its
basic constraints that it's an encryption-only key? 2440 says that a
top-level key must be capable of signing. Possible solutions include
ignoring the issue, and making that key a sub-key while generating a new
top-level key.)

I don't agree with making it a V3 key, but I know why it was done -- it was
expedient, and lots of good engineering is about expedience.

This is on the list of things to improve someday. Remember, though, that
every day an engineer is working on Feature X, they are not working on
Feature Y. If V3 keys are deprecated, it moves up in priority list.

    Jon

Date: Wed, 12 Mar 2003 11:50:27 +0000
From: Matthew Byng-Maddick <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Dash escaping consensus?
Organization: Colondot.net
Mail-Copies-To: never
Sender: [email-masked]

On Tue, Mar 11, 2003 at 02:42:42PM -0800, Jon Callas wrote:
> What's the consensus? Any line may be dash-escaped, or only "From "? I wrote
> it the first way, changed it to the second, and it seems we're back to the
> first.

My instinctive reaction on this is that ``An implementation MAY dash escape
any line, SHOULD dash escape lines commencing "From", and MUST dash escape
any line commencing in a dash.''

This would make it nice and unambiguous, IMO.

Also ``An implementation MUST strip the string "- " if it occurs at the
beginning of a line, and SHOULD warn on "-" and any character other than
a space at the beginning of a line.''

My 0.02 (insert favourite currency here)

MBM

-- 
Matthew Byng-Maddick         <[email-masked]>           http://colondot.net/

From: Mark Grant <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: RE: Dash escaping consensus?
Date: Wed, 12 Mar 2003 11:08:42 -0000
Sender: [email-masked]

> -----Original Message-----
> From: Jon Callas [mailto:[email-masked]]
> What's the consensus? Any line may be dash-escaped, or only 
> "From "?

Without thinking a lot about special cases I don't see any reason why you'd
want to dash-escape anything other than a dash or 'From' line, but saying
that any line can be dash-escaped would seem to make the decoding step
easier: that way any '- ' sequence can just be stripped from the message
without worrying about whether it's 'supposed' to be there. It seems
perfectly safe as any such sequence in the original message would have to be
dash-escaped.

	Mark

Date: Tue, 11 Mar 2003 14:42:42 -0800
Subject: Dash escaping consensus?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

What's the consensus? Any line may be dash-escaped, or only "From "? I wrote
it the first way, changed it to the second, and it seems we're back to the
first.

    Jon

To: Jeroen van Gelderen <[email-masked]>
Cc: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Further deprecating PGP2
Date: 11 Mar 2003 13:55:22 -0500
Lines: 15
Sender: [email-masked]

Jeroen van Gelderen <[email-masked]> writes:

> How are the messages stored?

mh-style, generally one file per message.  However I might have
a couple files with multiple PGP blocks.

> -J

-derek

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

Date: Tue, 11 Mar 2003 13:09:55 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked]
To: Derek Atkins <[email-masked]>
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Tuesday, Mar 11, 2003, at 12:24 US/Eastern, Derek Atkins wrote:
>> "An OpenPGP MAY support decryption of IDEA-encrypted messages but MUST
>> NOT generate them."
>
> I wouldn't say MUST NOT generate; I think it's a bit too strong.
> Generally, MUST NOT is used when using something would be detrimental
> (e.g. it would be a security problem, or cause immeasurable interop
> problems).  For example, one MUST NOT use "rot13" encryption.  I don't
> see why supporting/using IDEA falls into this category.  Therefore, I
> would say "SHOULD NOT encrypt using IDEA".  Is there some technical
> reason why IDEA "MUST NOT" be used?

You are right of course.

>> Killing of the sending of IDEA-encrypted messages also addresses my
>> concern: I will be able to decrypt any OpenPGP message sent to me
>> without being legally required to pay IDEA licensing fees. And Derek
>> can keep reading his existing mail.
>
> I think MAY decrypt and SHOULD NOT encrypt gets you the same thing,
> without making PGP.Com's implementation non-compliant for wanting to
> support older algorithms.

Yes.

> Basically I want a tool that will walk through my email messages and
> every time it finds a PGP block inside the message it replaces that
> PGP block with a new PGP block which is a re-encrypted version.  In 
> other
> words, it looks for files that look like:
>
>         blah blah blah
>         ----- BEGIN PGP MESSAGE -----
>         [radix64 snipped]
>         ----- END PGP MESSAGE ----
>         blah blah blah
>
> And replaces it with:
>
>         blah blah blah
>         ----- BEGIN PGP MESSAGE -----
>         [re-encrypted message in radix64 snipped]
>         ----- END PGP MESSAGE -----
>         blah blah blah
>
> I'll give you extra points if the timestamp on the message is not 
> changed.
> ;)

How are the messages stored?

-J

Date: Tue, 11 Mar 2003 11:28:26 -0600
To: Jon Callas <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: Re: Further deprecating PGP2
Cc: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 05:43 PM 3/10/2003 -0800, Jon Callas wrote:

>On 3/10/03 9:30 AM, "Derek Atkins" <[email-masked]> wrote:
>
>Second, as I have mentioned, in PGP Corp, we have effectively deprecated V3
>keys on our own, pushing people to V4. There's more we can do (like taking
>IDEA off the UI), but even if we were utterly radical and stopped generating
>all V3 keys, we wouldn't stop decrypting messages with V3 keys. That's
>ludicrous.

Importing an RSA certificate as a V3 key doesn't exactly sound like 
deprecation
to me. Any chance this will be corrected in PGP8 the near future? (Converting
a cert into a V4 key with appropriate algorithm preferences is not that hard.)

-mjm

To: Jeroen van Gelderen <[email-masked]>
Cc: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Further deprecating PGP2
Date: 11 Mar 2003 12:24:49 -0500
Lines: 72
Sender: [email-masked]

Jeroen van Gelderen <[email-masked]> writes:

> Derek,
> 
> On Monday, Mar 10, 2003, at 12:30 US/Eastern, Derek Atkins wrote:
> > The problem is not the use of the program (indeed, I haven't run pgp
> > 2.6 in ages, I've been running pgp6).  The problem is all the data
> > encrypted using old keys and algorithms.
> >
> > I've got thousands of messages encrypted in my PGP2 RSA key using IDEA
> > and MD5.  Frankly, I don't want to go through my mail and re-encrypt
> > all those messages using OpenPGP encryption -- I want to just be able
> > to read those messages in the future.
> 
> Ah, thanks for the use case. I think I understand. I think that could
> be achieved by you using an OpenPGP program that MAY support IDEA
> decryption, no?

Sure, that would be fine...

> "An OpenPGP MAY support decryption of IDEA-encrypted messages but MUST
> NOT generate them."

I wouldn't say MUST NOT generate; I think it's a bit too strong.
Generally, MUST NOT is used when using something would be detrimental
(e.g. it would be a security problem, or cause immeasurable interop
problems).  For example, one MUST NOT use "rot13" encryption.  I don't
see why supporting/using IDEA falls into this category.  Therefore, I
would say "SHOULD NOT encrypt using IDEA".  Is there some technical
reason why IDEA "MUST NOT" be used?

> Killing of the sending of IDEA-encrypted messages also addresses my
> concern: I will be able to decrypt any OpenPGP message sent to me
> without being legally required to pay IDEA licensing fees. And Derek
> can keep reading his existing mail.

I think MAY decrypt and SHOULD NOT encrypt gets you the same thing,
without making PGP.Com's implementation non-compliant for wanting to
support older algorithms.

> > Admittedly, if there were a tool I could use that would do the
> > re-encryption for me I might consider it,
> 
> What kind of message formats would it be required to handle?

Basically I want a tool that will walk through my email messages and
every time it finds a PGP block inside the message it replaces that
PGP block with a new PGP block which is a re-encrypted version.  In other
words, it looks for files that look like:

        blah blah blah
        ----- BEGIN PGP MESSAGE -----
        [radix64 snipped]
        ----- END PGP MESSAGE ----
        blah blah blah

And replaces it with:

        blah blah blah
        ----- BEGIN PGP MESSAGE -----
        [re-encrypted message in radix64 snipped]
        ----- END PGP MESSAGE -----
        blah blah blah

I'll give you extra points if the timestamp on the message is not changed.
;)

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

Date: Mon, 10 Mar 2003 17:43:44 -0800
Subject: Re: Further deprecating PGP2
From: Jon Callas <[email-masked]>
To: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/10/03 9:30 AM, "Derek Atkins" <[email-masked]> wrote:

> 
> The problem is not the use of the program (indeed, I haven't run pgp
> 2.6 in ages, I've been running pgp6).  The problem is all the data
> encrypted using old keys and algorithms.
> 
> I've got thousands of messages encrypted in my PGP2 RSA key using IDEA
> and MD5.  Frankly, I don't want to go through my mail and re-encrypt
> all those messages using OpenPGP encryption -- I want to just be able
> to read those messages in the future.
> 
> Admittedly, if there were a tool I could use that would do the
> re-encryption for me I might consider it, but I have no inclination to
> write such a tool at this moment.  However, this means that I will
> always run a version of PGP that can read those messages.  If RSA,
> IDEA, and MD5 are not available algorithms, that's a clue to me that I
> shouldn't upgrade.

Two small comments --

First, again, what's being discussed is deprecating, not dropping. It would
be a mistake to strand people, and there are ways to keep this from
happening. We've discussed a number of them here. The decision I'm looking
for is whether we should deprecate.

Second, as I have mentioned, in PGP Corp, we have effectively deprecated V3
keys on our own, pushing people to V4. There's more we can do (like taking
IDEA off the UI), but even if we were utterly radical and stopped generating
all V3 keys, we wouldn't stop decrypting messages with V3 keys. That's
ludicrous.

The people who don't have IDEA licenses and consequently don't have it now
would probably be the only ones who wouldn't do it after deprecating.
Deprecating is an official statement that no expansion should be made, and
contraction is good. It isn't dropping.

For example, for a long time in C, "=op" was allowed, but deprecated. (It
could be banned now, I don't know.)

If you wrote something like

    i =- 1;

The compiler knew it was the same as

    i -= 1;

But it would cluck its tongue at you and give you warnings about deprecated
features. I'm not suggesting there should be warnings, we should just start
making it clear that V3 keys are going away sometime between now and say
2010.

    Jon

Date: Tue, 11 Mar 2003 14:33:57 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jeroen van Gelderen <[email-masked]> writes:

>Or if that really, really is considered too weak: "An OpenPGP implementation
>[MAY/SHOULD] support decryption of IDEA-encrypted messages but MUST NOT 
>generate them."

Sounds good to me (with an additional MUST NOT for generation of v3 keys, to
nail that issue as well).

Peter.

Date: Tue, 11 Mar 2003 01:19:56 +0000
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: David Shaw <[email-masked]>, Jon Callas <[email-masked]>, Peter Gutmann <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Further deprecating PGP2
Sender: [email-masked]

Hmm I am missing a couple of negatives here for this to make sense,
this is better:

One could hardly consider an implementation bad that encrypted with
IDEA when IDEA is the only defined algorithm for that key (and this is
what I'd read SHOULD NOT to mean; MUST NOT would make the
implementation non-conformant even!)

Adam

On Tue, Mar 11, 2003 at 12:06:01AM +0000, Adam Back wrote:
> 
> I agree.  SHOULD is fine, but if people have strong feelings about it
> MAY is ok also and has similar effect for implementations that care to
> add backwards compatibility.
> 
> One could hardly consider an implementation bad that failed to encrypt
> with IDEA when IDEA is the only defined algorithm for that key (and
> this is what I'd read SHOULD NOT to mean; MUST NOT would make the
> implementationon-conformant even!)
> 
> Adam
> 
> On Mon, Mar 10, 2003 at 06:34:14PM -0500, Derek Atkins wrote:
> > 
> > David Shaw <[email-masked]> writes:
> > 
> > > Even better, even word games can become tiresome.
> > > 
> > > What do you advocate with regards to IDEA - SHOULD NOT?  MUST NOT?
> > > something else?
> > 
> > I would NOT advocate MUST NOT.  In fact, I wouldn't even leave it as a
> > foo-NOT.  I'd still leave it in the positive.  I'd still rather keep
> > it as 'SHOULD', but 'MAY' is reasonable.  Why is IDEA so detrimental
> > that you MUST NOT use it?

Date: Tue, 11 Mar 2003 00:06:01 +0000
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: David Shaw <[email-masked]>, Jon Callas <[email-masked]>, Peter Gutmann <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Further deprecating PGP2
Sender: [email-masked]

I agree.  SHOULD is fine, but if people have strong feelings about it
MAY is ok also and has similar effect for implementations that care to
add backwards compatibility.

One could hardly consider an implementation bad that failed to encrypt
with IDEA when IDEA is the only defined algorithm for that key (and
this is what I'd read SHOULD NOT to mean; MUST NOT would make the
implementationon-conformant even!)

Adam

On Mon, Mar 10, 2003 at 06:34:14PM -0500, Derek Atkins wrote:
> 
> David Shaw <[email-masked]> writes:
> 
> > Even better, even word games can become tiresome.
> > 
> > What do you advocate with regards to IDEA - SHOULD NOT?  MUST NOT?
> > something else?
> 
> I would NOT advocate MUST NOT.  In fact, I wouldn't even leave it as a
> foo-NOT.  I'd still leave it in the positive.  I'd still rather keep
> it as 'SHOULD', but 'MAY' is reasonable.  Why is IDEA so detrimental
> that you MUST NOT use it?

Date: Mon, 10 Mar 2003 19:00:38 -0500
From: David Shaw <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: Jon Callas <[email-masked]>, Jeroen van Gelderen <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], OpenPGP <[email-masked]>, [email-masked]
Subject: Re: Further deprecating PGP2
Mail-Followup-To: Derek Atkins <[email-masked]>, Jon Callas <[email-masked]>, Jeroen van Gelderen <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], OpenPGP <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Mar 10, 2003 at 06:34:14PM -0500, Derek Atkins wrote:
> David Shaw <[email-masked]> writes:
> 
> > Even better, even word games can become tiresome.
> > 
> > What do you advocate with regards to IDEA - SHOULD NOT?  MUST NOT?
> > something else?
> 
> I would NOT advocate MUST NOT.  In fact, I wouldn't even leave it as a
> foo-NOT.  I'd still leave it in the positive.  I'd still rather keep
> it as 'SHOULD', but 'MAY' is reasonable.  Why is IDEA so detrimental
> that you MUST NOT use it?

Speaking strictly in the OpenPGP context, IDEA gives us nothing
special.  There are no interoperability issues due to the preferences
system, so IDEA is just other optional cipher in the standard.  Why
should it get special treatment (SHOULD)?

Speaking in the PGP 2.x interoperability context, IDEA is necessary.
However, an OpenPGP implementation that does not need to interoperate
with PGP 2.x doesn't need it, and so a SHOULD there is inappropriate.

Either way, I don't advocate MUST NOT.  I'm in favor of the way the
draft currently reads (which is MAY along with an explanation of the
PGP 2.x issue) .  I do have some sympathy for SHOULD NOT because of
the patent situation.

David

To: David Shaw <[email-masked]>
Cc: Jon Callas <[email-masked]>, Jeroen van Gelderen <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], OpenPGP <[email-masked]>, [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Further deprecating PGP2
Date: 10 Mar 2003 18:34:14 -0500
Lines: 20
Sender: [email-masked]

David Shaw <[email-masked]> writes:

> Even better, even word games can become tiresome.
> 
> What do you advocate with regards to IDEA - SHOULD NOT?  MUST NOT?
> something else?

I would NOT advocate MUST NOT.  In fact, I wouldn't even leave it as a
foo-NOT.  I'd still leave it in the positive.  I'd still rather keep
it as 'SHOULD', but 'MAY' is reasonable.  Why is IDEA so detrimental
that you MUST NOT use it?

> David

-derek

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

Date: Mon, 10 Mar 2003 17:45:35 -0500
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Jeroen van Gelderen <[email-masked]>, Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], OpenPGP <[email-masked]>, [email-masked]
Subject: Re: Further deprecating PGP2
Mail-Followup-To: Jon Callas <[email-masked]>, Jeroen van Gelderen <[email-masked]>, Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], OpenPGP <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Mar 10, 2003 at 02:35:27PM -0800, Jon Callas wrote:
> On 3/10/03 1:26 PM, "David Shaw" <[email-masked]> wrote:
> 
> > If a program implements both RFC-1991 and OpenPGP, and RFC-1991
> > requires IDEA, and OpenPGP requires no IDEA.... well, we could really
> > tie some people in knots.  It's really just word games though: does
> > the "OpenPGP side" of the program have IDEA?  No, but...
> 
> RFC 1991 was never standards track. It is informational. There are no knots.

Even better, even word games can become tiresome.

What do you advocate with regards to IDEA - SHOULD NOT?  MUST NOT?
something else?

David

Date: Mon, 10 Mar 2003 14:35:27 -0800
Subject: Re: Further deprecating PGP2
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, Jeroen van Gelderen <[email-masked]>
CC: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/10/03 1:26 PM, "David Shaw" <[email-masked]> wrote:

> If a program implements both RFC-1991 and OpenPGP, and RFC-1991
> requires IDEA, and OpenPGP requires no IDEA.... well, we could really
> tie some people in knots.  It's really just word games though: does
> the "OpenPGP side" of the program have IDEA?  No, but...

RFC 1991 was never standards track. It is informational. There are no knots.

    Jon

Date: Mon, 10 Mar 2003 16:26:54 -0500
From: David Shaw <[email-masked]>
To: Jeroen van Gelderen <[email-masked]>
Cc: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Mail-Followup-To: Jeroen van Gelderen <[email-masked]>, Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Mar 10, 2003 at 04:03:17PM -0500, Jeroen van Gelderen wrote:
> 
> On Monday, Mar 10, 2003, at 15:16 US/Eastern, David Shaw wrote:
> >>Killing of the sending of IDEA-encrypted messages also addresses my
> >>concern: I will be able to decrypt any OpenPGP message sent to me
> >>without being legally required to pay IDEA licensing fees. And Derek
> >>can keep reading his existing mail.
> >
> >I'm not sure if I understand this comment.  Can you clarify?  A
> >message encrypted by an OpenPGP program to an OpenPGP key "MUST NOT
> >use a symmetric algorithm that is not in the recipient's preference
> >list." (section 12.1) If you don't have a preference for IDEA, then
> >anyone sending you an OpenPGP message that uses IDEA is already
> >non-compliant.
> 
> I guess I'm happy then :)
> 
> Is a PGP2 key with IDEA listed as its single preferred algorithm 
> considered an OpenPGP key? (I hope not, otherwise I still can't send 
> all OpenPGP messages without a license.)

PGP 2.x keys don't have preferences.  It is possible to "upgrade" a
PGP 2.x key with an OpenPGP self-signature and thus gain a preference
list.  In that case, I'd argue that the key should be treated as an
OpenPGP key, which means that a preference list consisting of only
"IDEA" would be interpreted as "IDEA or 3DES".  This is how GnuPG
handles this case, by the way.

> >  I also support deprecating the PGP 2.x
> >features in OpenPGP in general.  Any program that wants to implement
> >PGP 2.x functionality can still do that without affecting their
> >OpenPGP compliance.
> 
> Except if IDEA is marked as MUST NOT, right? So I should retract that 
> particular proposal.

If a program implements both RFC-1991 and OpenPGP, and RFC-1991
requires IDEA, and OpenPGP requires no IDEA.... well, we could really
tie some people in knots.  It's really just word games though: does
the "OpenPGP side" of the program have IDEA?  No, but...

SHOULD NOT, with an explantion of why, sounds good to me.

David

Date: Mon, 10 Mar 2003 16:03:17 -0500
Subject: Re: Further deprecating PGP2
Cc: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: David Shaw <[email-masked]>
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Monday, Mar 10, 2003, at 15:16 US/Eastern, David Shaw wrote:
>> Killing of the sending of IDEA-encrypted messages also addresses my
>> concern: I will be able to decrypt any OpenPGP message sent to me
>> without being legally required to pay IDEA licensing fees. And Derek
>> can keep reading his existing mail.
>
> I'm not sure if I understand this comment.  Can you clarify?  A
> message encrypted by an OpenPGP program to an OpenPGP key "MUST NOT
> use a symmetric algorithm that is not in the recipient's preference
> list." (section 12.1) If you don't have a preference for IDEA, then
> anyone sending you an OpenPGP message that uses IDEA is already
> non-compliant.

I guess I'm happy then :)

Is a PGP2 key with IDEA listed as its single preferred algorithm 
considered an OpenPGP key? (I hope not, otherwise I still can't send 
all OpenPGP messages without a license.)

> You could be sent a PGP 2.x message that uses IDEA, but PGP 2.x isn't
> subject to the OpenPGP spec.

Definitely.

> That said, I do support removing the SHOULD from IDEA (and the current
> draft has already done this).

Yes, that is lovely.

>   I also support deprecating the PGP 2.x
> features in OpenPGP in general.  Any program that wants to implement
> PGP 2.x functionality can still do that without affecting their
> OpenPGP compliance.

Except if IDEA is marked as MUST NOT, right? So I should retract that 
particular proposal.

Cheers,
-J

Date: Mon, 10 Mar 2003 15:16:15 -0500
From: David Shaw <[email-masked]>
To: Jeroen van Gelderen <[email-masked]>
Cc: Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Mail-Followup-To: Jeroen van Gelderen <[email-masked]>, Derek Atkins <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Mon, Mar 10, 2003 at 02:18:04PM -0500, Jeroen van Gelderen wrote:

> Ah, thanks for the use case. I think I understand. I think that could 
> be achieved by you using an OpenPGP program that MAY support IDEA 
> decryption, no?
> 
> "An OpenPGP MAY support decryption of IDEA-encrypted messages but MUST 
> NOT generate them."
> 
> Or if that really, really is considered too weak: "An OpenPGP 
> implementation SHOULD support decryption of IDEA-encrypted messages but 
> MUST NOT generate them."
> 
> Is there any objection to the MUST NOT bit? I would think that 
> addressing Derek's use case removes any barrier for people to upgrade 
> to a recent OpenPGP implementation. And in that case we should really 
> kill of the support for those who insist on using outdated software. We 
> don't want to support Mediacrypt until 2011.
> 
> Killing of the sending of IDEA-encrypted messages also addresses my 
> concern: I will be able to decrypt any OpenPGP message sent to me 
> without being legally required to pay IDEA licensing fees. And Derek 
> can keep reading his existing mail.

I'm not sure if I understand this comment.  Can you clarify?  A
message encrypted by an OpenPGP program to an OpenPGP key "MUST NOT
use a symmetric algorithm that is not in the recipient's preference
list." (section 12.1) If you don't have a preference for IDEA, then
anyone sending you an OpenPGP message that uses IDEA is already
non-compliant.

You could be sent a PGP 2.x message that uses IDEA, but PGP 2.x isn't
subject to the OpenPGP spec.

That said, I do support removing the SHOULD from IDEA (and the current
draft has already done this).  I also support deprecating the PGP 2.x
features in OpenPGP in general.  Any program that wants to implement
PGP 2.x functionality can still do that without affecting their
OpenPGP compliance.

David

Date: Mon, 10 Mar 2003 14:18:04 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked]
To: Derek Atkins <[email-masked]>
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

Derek,

On Monday, Mar 10, 2003, at 12:30 US/Eastern, Derek Atkins wrote:
> The problem is not the use of the program (indeed, I haven't run pgp
> 2.6 in ages, I've been running pgp6).  The problem is all the data
> encrypted using old keys and algorithms.
>
> I've got thousands of messages encrypted in my PGP2 RSA key using IDEA
> and MD5.  Frankly, I don't want to go through my mail and re-encrypt
> all those messages using OpenPGP encryption -- I want to just be able
> to read those messages in the future.

Ah, thanks for the use case. I think I understand. I think that could 
be achieved by you using an OpenPGP program that MAY support IDEA 
decryption, no?

"An OpenPGP MAY support decryption of IDEA-encrypted messages but MUST 
NOT generate them."

Or if that really, really is considered too weak: "An OpenPGP 
implementation SHOULD support decryption of IDEA-encrypted messages but 
MUST NOT generate them."

Is there any objection to the MUST NOT bit? I would think that 
addressing Derek's use case removes any barrier for people to upgrade 
to a recent OpenPGP implementation. And in that case we should really 
kill of the support for those who insist on using outdated software. We 
don't want to support Mediacrypt until 2011.

Killing of the sending of IDEA-encrypted messages also addresses my 
concern: I will be able to decrypt any OpenPGP message sent to me 
without being legally required to pay IDEA licensing fees. And Derek 
can keep reading his existing mail.

> Admittedly, if there were a tool I could use that would do the
> re-encryption for me I might consider it,

What kind of message formats would it be required to handle?

> but I have no inclination to
> write such a tool at this moment.  However, this means that I will
> always run a version of PGP that can read those messages.  If RSA,
> IDEA, and MD5 are not available algorithms, that's a clue to me that I
> shouldn't upgrade.

Cheers,
-J

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Further deprecating PGP2
Date: 10 Mar 2003 12:30:56 -0500
Lines: 35
Sender: [email-masked]

The problem is not the use of the program (indeed, I haven't run pgp
2.6 in ages, I've been running pgp6).  The problem is all the data
encrypted using old keys and algorithms.

I've got thousands of messages encrypted in my PGP2 RSA key using IDEA
and MD5.  Frankly, I don't want to go through my mail and re-encrypt
all those messages using OpenPGP encryption -- I want to just be able
to read those messages in the future.

Admittedly, if there were a tool I could use that would do the
re-encryption for me I might consider it, but I have no inclination to
write such a tool at this moment.  However, this means that I will
always run a version of PGP that can read those messages.  If RSA,
IDEA, and MD5 are not available algorithms, that's a clue to me that I
shouldn't upgrade.

-derek

[email-masked] (Peter Gutmann) writes:

> In that case they can use an OpenPGP version (in fact I would hope that a
> business isn't still using 10-year-old DOS-based software in their commercial
> operations).  I would imagine that most people still sticking to PGP 2.x are
> doing so because they've used it for years and are comfortable with it, and by
> extension would be individual users who fall under the free-use terms.  It
> seems like a bit of a non-issue to me - as Derek said, make it a MUST NOT
> generate 2.x-style keys but SHOULD still support the message format, that'll
> have the required effect.
> 
> Peter.

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

Date: Mon, 10 Mar 2003 11:14:55 -0500
Subject: Re: Dash-escaping clarification
Cc: "David Shaw" <[email-masked]>, <[email-masked]>
To: "Dominikus Scherkl" <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Monday, Mar 10, 2003, at 05:51 US/Eastern, Dominikus Scherkl wrote:

>
>> I don't see how there would be a problem in reversing the
>> transformation.
>>
>> - bullet point
>> becomes
>> - - bullet point
>> and reverses back to
>> - bullet point
>>
>> random text
>> becomes
>> - random text
>> and reverses back to
>> random text
>
> MAY means: arbitrary lines may get a dash-escape, others do not.
> so how do you manage to recognise which leading "- " were there
> before encoding and which were not, without looking at the
> following text?

The spec also states that all lines starting with "-" are escaped 
unconditionally. Which means that any armored line starting with a "- " 
is an escaped line because it cannot be a non-escaped line. And thus 
can be stripped off its "- " prefix without looking at the following 
text.

> Now this is easy: a sequence "- -" becomes "-" and "- From" becomes
> "From", anything else is left unchanged.
> But if any other lines MAY be escaped, looking at the context
> doesn't help any more. Dashes are used also to mark insertions
> - at least in german this is common - and how can a parser find
> out if the "- " in the above line is intentional? or that in the next?
> - From all solutions I prefer not to allow escaping other then

It doesn't have to. Your example will always be translated to:

- - at least in german this is common - and how can a parser find
out if the "- " in the above line is intentional? or that in the next?
- - From all solutions I prefer not to allow escaping other then

and thus can be unescaped unambiguously.

Allowing every line to be escaped yields a simpler unescaping 
algorithm. Simplicity is a selling point when security is concerned. It 
is also compatible with PGP behaviour dating back to God knows when and 
thus will not cause any problems that are not already apparent in PGP.

Cheers,
-J

Date: Mon, 10 Mar 2003 08:39:13 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Mar 10, 2003 at 11:51:43AM +0100, Dominikus Scherkl wrote:
> 
> > I don't see how there would be a problem in reversing the
> > transformation.
> > 
> > - bullet point
> > becomes
> > - - bullet point
> > and reverses back to
> > - bullet point
> > 
> > random text
> > becomes
> > - random text
> > and reverses back to
> > random text
> 
> MAY means: arbitrary lines may get a dash-escape, others do not.
> so how do you manage to recognise which leading "- " were there
> before encoding and which were not, without looking at the
> following text?

This is not correct.  The MAY is for additional lines, after the
regular "-" encoding is done.

To be clear, the current rule is:
   1) Escape any lines beginning with '-'.

There is also an undocumented rule #2:
   2) Escape any lines beginning with "From".

The proposed change is:

   1) Escape any lines beginning with "-".
   2) Escape any other lines you want.

The only change is in #2.

David

To: <[email-masked]>
Subject: Re: Dash-escaping clarification
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 10 Mar 2003 13:38:56 +0100
Sender: [email-masked]

On Mon, 10 Mar 2003 11:51:43 +0100, Dominikus Scherkl said:

> - at least in german this is common - and how can a parser find
> out if the "- " in the above line is intentional? or that in the next?

It does not need to.  There are 2 ways to convert dash escaped text:

 1. Look for a line starting with a dash and check whether the next
    character is a space.  If it is not a space bail out with an
    error: "not an OpenPGP conform message"

 2. Look for a line starting with a dash and a space (or end-of-line)
    and remove it; copy verbatim in all other cases.

Of course, this should only be done while in a -----BEGIN/END section.

The second approach is the simplest and what most applications do.

> - From all solutions I prefer not to allow escaping other then
> those starting with "-" or "From" - it simply works, and I think

This requires extra logic and a 6 byte look-ahead (" From ") and you
gain nothing by it.  With the straighforward approach you can simple
sed the dash escaped text.

KISS.

Shalom-Salam,

   Werner

Content-Class: urn:content-classes:message
Subject: RE: Dash-escaping clarification
Date: Mon, 10 Mar 2003 11:51:43 +0100
From: "Dominikus Scherkl" <[email-masked]>
To: "David Shaw" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

> I don't see how there would be a problem in reversing the
> transformation.
> 
> - bullet point
> becomes
> - - bullet point
> and reverses back to
> - bullet point
> 
> random text
> becomes
> - random text
> and reverses back to
> random text

MAY means: arbitrary lines may get a dash-escape, others do not.
so how do you manage to recognise which leading "- " were there
before encoding and which were not, without looking at the
following text?
Now this is easy: a sequence "- -" becomes "-" and "- From" becomes
"From", anything else is left unchanged.
But if any other lines MAY be escaped, looking at the context
doesn't help any more. Dashes are used also to mark insertions
- at least in german this is common - and how can a parser find
out if the "- " in the above line is intentional? or that in the next?
- From all solutions I prefer not to allow escaping other then
those starting with "-" or "From" - it simply works, and I think
your solution won't. Maybe it will take a while, but one day
we may worry about another head-aching problem introduced in the
long ago 2003-version of pgp, and can't help it in other ways
as to once again restrict it to all the odd cases which become
relevant or change the MAY to a MUST - ending up with CRLF beeing
extendet to "CRLF- ".

-- 
Dominikus Scherkl
[email-masked]

Date: Sun, 09 Mar 2003 16:46:33 -0800
Subject: Re: SHOULD -> MAY (Re: Further deprecating PGP2)
From: Jon Callas <[email-masked]>
To: "Jeroen C. van Gelderen" <[email-masked]>, "Michael H. Warfield" <[email-masked]>, OpenPGP <[email-masked]>
CC: Peter Gutmann <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/9/03 2:13 PM, "Jeroen C. van Gelderen" <[email-masked]> wrote:

> As it stands, OpenPGP implementors are urged[*] to support this
> outdated and non-royalty-free message format. Yet nobody should be
> urged to perpetuate patent encumbered software if there is a gratis
> (GnuPG) and fully functional (more secure even) alternative.
> 

In spite of the fact that I support deprecating all PGP 2 features,
including IDEA, I think that "SHOULD" means "urge" is a bit strong.

My informal interpretation of SHOULD is that if you just picked up the
standard and are implementing from it, do the SHOULDs unless you know why.
If you run into something like a patent issue, then you know why it's a
SHOULD (as opposed to a MUST or MAY).

A further bit of cleverness on a developer's part is to note that if
something is a SHOULD, there's probably a controversy around it -- some
reason it's not a MUST, and some reason it's not a MAY. It's either
something people would like to get rid of but can't, or some sizable
minority is enthusiastic about, and couldn't get enough support to make it a
requirement.

Now beyond this, I agree with the vast majority of what Jeroen has said. In
PGP, we have effectively deprecated V3 keys since 2001. V3 keys are called
"Legacy RSA keys" and you have to do "Expert" key generation to get one.
There are also warnings that pop up when you create one.

    Jon

Date: Sun, 9 Mar 2003 17:13:42 -0500
Subject: SHOULD -> MAY (Re: Further deprecating PGP2)
Cc: Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
To: "Michael H. Warfield" <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Sunday, Mar 9, 2003, at 12:37 US/Eastern, Michael H. Warfield wrote:

> On Sat, Mar 08, 2003 at 07:07:18PM +1300, Peter Gutmann wrote:
>
>> Werner Koch <[email-masked]> writes:
>
>>> Implementing IDEA is trivial but as it is now, it is not possible to 
>>> use any
>>> software without paying royalities to Ascom.
>
>> I've been using it for years without paying royalties to Ascom, and 
>> so has
>> most of the rest of the PGP-using world.  It's only if you're selling 
>> it for
>> more than $10K (from memory) that you need to talk to Ascom.
>
> 	Actually, it's far worse that this.  I exchanged some E-Mail with
> Richard Strab, the CEO of MediaCrypt, (the license vendor for Ascom) 
> and
> he made it quite clear that their definition of "commercial users" 
> included
> any and all non-profit organizations and anyone who was not using it 
> for
> personal individual use (and even personal use was not acceptable if 
> you
> were using it to communication with a "commercial" entity, even if that
> entity was a non-profit professional organization or your church or 
> your
> school).  If you root around MediaCrypt's site you eventually find 
> their
> draconian definition of what they feel constitutes commercial and
> non-commercial and, for the life of me, I can't find much that they
> CAN'T construe to be commercial and demand royalties.  You end up 
> looking
> for a really tiny needle (non-commercial) in a really broad and hazy
> haystack (commercial).
>
> 	From what I understand exchanging mail with some of my professional
> counterparts at some universities, a number of universities already 
> have
> blanket licenses negotiated and paid for.  Their use is covered, NOT 
> because
> it's non-commercial but, because they already paid for their 
> organization's
> license.

Thanks for the information. This was my understanding too. All of the 
non-exempt entities listed above will have to pay money to read 
IDEA-encrypted OpenPGP messages. Or, in fact to interoperate with PGP2 
applications in general IIANM.

As it stands, OpenPGP implementors are urged[*] to support this 
outdated and non-royalty-free message format. Yet nobody should be 
urged to perpetuate patent encumbered software if there is a gratis 
(GnuPG) and fully functional (more secure even) alternative.

Getting OpenPGP adopted and used is plenty difficult enough as is. 
Instead of insisting that the status quo be maintained we should 
concentrate on removing any and all barriers to wider spread adoption. 
Making sure that OpenPGP is completely royalty free is one thing that 
helps. Removing complexity from the standard is another approach.

I want to be able to say "Send me an OpenPGP message!" *AND* be legally 
allowed to decrypt whatever OpenPGP message I am sent. I don't have the 
luxury of a university buying me a blanket license with taxpayer money. 
I don't have a luxury of being paid and still be considered a 
non-commercial entity.

Labeling support for IDEA messages RECOMMENDED[*] as is the case now 
sends the wrong message to implementors. Marking IDEA messages 
OPTIONAL[**] (with "MAY") avoids this trap. And stating that IDEA 
messages SHOULD NOT be sent ensures that all alternatives will be tried 
first before the application falls back to IDEA.

Cheers,
-J

[*] "SHOULD: This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course."

[**] "MAY: This word, or the adjective "OPTIONAL", mean that an item is
      truly optional..."

Date: Sun, 9 Mar 2003 12:37:46 -0500
From: "Michael H. Warfield" <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Sender: [email-masked]

--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 08, 2003 at 07:07:18PM +1300, Peter Gutmann wrote:

> Werner Koch <[email-masked]> writes:

> >Implementing IDEA is trivial but as it is now, it is not possible to use=
 any
> >software without paying royalities to Ascom.

> I've been using it for years without paying royalties to Ascom, and so has
> most of the rest of the PGP-using world.  It's only if you're selling it =
for
> more than $10K (from memory) that you need to talk to Ascom.

	Actually, it's far worse that this.  I exchanged some E-Mail with
Richard Strab, the CEO of MediaCrypt, (the license vendor for Ascom) and
he made it quite clear that their definition of "commercial users" included
any and all non-profit organizations and anyone who was not using it for
personal individual use (and even personal use was not acceptable if you
were using it to communication with a "commercial" entity, even if that
entity was a non-profit professional organization or your church or your
school).  If you root around MediaCrypt's site you eventually find their
draconian definition of what they feel constitutes commercial and
non-commercial and, for the life of me, I can't find much that they
CAN'T construe to be commercial and demand royalties.  You end up looking
for a really tiny needle (non-commercial) in a really broad and hazy
haystack (commercial).

	From what I understand exchanging mail with some of my professional
counterparts at some universities, a number of universities already have
blanket licenses negotiated and paid for.  Their use is covered, NOT because
it's non-commercial but, because they already paid for their organization's
license.

> Peter.

	Mike
--=20
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  /\/\|=3Dmhw=3D|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/=
mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

--EeQfGwPcQSOJBaQU
Content-Type: application/pgp-signature
Content-Disposition: inline

--EeQfGwPcQSOJBaQU--

Date: Sun, 9 Mar 2003 02:34:44 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
To: [email-masked] (Peter Gutmann)
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Sunday, Mar 9, 2003, at 01:27 US/Eastern, Peter Gutmann wrote:

>
> Jeroen van Gelderen <[email-masked]> writes:
>
>> How can my copy of OpenPGP support an IDEA-encrypted message if I am 
>> not
>> allowed to use IDEA to decrypt it?
>
> How many people are really going to be affected by this?  As I said in 
> my
> previous message, I would imagine that the majority of people still 
> using 2.x
> are individuals/personal-use, which means they have no problems using 
> IDEA.
> Commercial users will (presumably) be using a licensed version, in 
> which case
> it doesn't matter either.

In which case either party doesn't care about their messages not being 
branded OpenPGP compliant because they will be sending the messages to 
other 2.x users. So PGP2 messages can be stripped out of the standard 
that contemporary PGP users adhere to.

>  You need to distinguish between "We can't use IDEA
> for commercial/licensing reasons" and "We refuse to consider IDEA for
> ideological reasons".  I suspect instances of the former are pretty 
> rare in
> practice.  Give me some real-world examples

I am not exactly sure how you are interpreting "I don't want to require 
people to pay" as "I have an issue with patents". Iff the latter were 
true I would object against CAST-5 too.

I have a reasonably large set of PGP messages that I can't legally 
decrypt because they are encrypted with IDEA. Those messages should not 
be considered OpenPGP compliant. Most people who sent those have now 
switched to GNUPG.

I think that in practice most people ignore the IDEA patent because 
Ascom is pretty lenient. Or companies like PGP buy a wholesale license 
on their behalf. But anyone who is using GnuPG in a commercial setting 
cannot legally decrypt IDEA messages without a license. Which means 
they cannot decrypt OpenPGP-compliant messages. So we should make sure 
they don't end up in that situation. They should be able to say "Hey, 
please send me an OpenPGP message instead!".

There is a reason that Internet standards tend to be completely patent 
free. OpenPGP is no exception.

>  where significant use of PGP was
> affected by the current situation with IDEA, and show me how MUST NOT 
> IDEA
> would have fixed this.

The MUST NOT was not a central point of my argument. The central point 
was changing the SHOULD to MAY. People SHOULD NOT actively support 
PGP2, they MAY do so however. It is the difference between it being 
optional (MAY) and desirable (SHOULD). It's time to kill of the old 
baggage to reduce complexity. And definitely if it costs money.

I doubt PGP use was ever 'significant'. I was hoping that simplifying 
the standard and ripping out the old baggage would give OpenPGP a push 
in the right direction. Implementing OpenPGP is horrific enough as-is.

Cheers,
-J

Date: Sun, 9 Mar 2003 02:11:02 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
To: [email-masked] (Peter Gutmann)
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Sunday, Mar 9, 2003, at 01:27 US/Eastern, Peter Gutmann wrote:

> Jeroen van Gelderen <[email-masked]> writes:
>
>> How can my copy of OpenPGP support an IDEA-encrypted message if I am 
>> not
>> allowed to use IDEA to decrypt it?
>
> How many people are really going to be affected by this?

Any implementor of an OpenPGP-compliant application. As long as I 
'SHOULD' handle IDEA-encrypted mail people will consider my application 
to be incomplete if it doesn't.

Anybody who uses -say- the Cryptix OpenPGP library in a commercial 
setting will have to get themselves a license or disable the IDEA 
functionality.

For what? For people who insist on using outdated and deprecated 
software? Why would they expect a modern standard to cater for them?

Why not get rid of IDEA? People MAY implement IDEA/PGP2-support in 
their otherwise OpenPGP-compliant applications. Such an extra feature 
will not render the application non-compliant. But rip the 'SHOULD' out 
of the standard. Make sure that people who send PGP2 messages do 
realize that they are not sending OpenPGP messages and that they cannot 
expect OpenPGP compliant apps to deal with them. In particular, let's 
make very clear that they cannot expect a PGP2 response back.

>   As I said in my
> previous message, I would imagine that the majority of people still 
> using 2.x
> are individuals/personal-use, which means they have no problems using 
> IDEA.

Then they don't care about their use of IDEA being OpenPGP-endorsed or 
not. I do care about the fact that I am not legally allowed to decrypt 
their messages when I receive them. And you are giving them the 
ammunition to say "Hey, my message is OpenPGP compliant!".

The issue is not them. The issue is that everybody else 'SHOULD' handle 
their outdated messages. I don't care what you use or do, I care about 
what I am supposed to do according to the standard. And according to 
the standard I 'SHOULD' support a long-deprecated type of message and 
thus I 'SHOULD' pay royalties.

I want *every* OpenPGP implementation to be able to handle OpenPGP 
messages without paying royalties to anyone. And thus do I want 
IDEA-encrypted messages to not carry the OpenPGP seal of approval. 
There is no need for that.

> Commercial users will (presumably) be using a licensed version, in 
> which case
> it doesn't matter either.  You need to distinguish between "We can't 
> use IDEA
> for commercial/licensing reasons" and "We refuse to consider IDEA for
> ideological reasons".

That is easy for you to say. You can create an IDEA-message for free 
because you don't work in a commercial setting. I can't legally decrypt 
your IDEA/OpenPGP message because I don't have an IDEA license. What 
kind of interoperability is that?

The point is that using the full standard including 'SHOULD's in a 
commercial setting requires money. That has nothing to do with 
ideology. Zip. Zilch. Principle, yes. But not ideology. Internet 
standards are kept patent free for practical reasons, not ideological 
reasons.

Wasn't it you who called for a patent-free OCB? Why was that again?

Cheers,
-J

Date: Sun, 9 Mar 2003 19:27:16 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Jeroen van Gelderen <[email-masked]> writes:

>How can my copy of OpenPGP support an IDEA-encrypted message if I am not
>allowed to use IDEA to decrypt it? 

How many people are really going to be affected by this?  As I said in my
previous message, I would imagine that the majority of people still using 2.x
are individuals/personal-use, which means they have no problems using IDEA.
Commercial users will (presumably) be using a licensed version, in which case
it doesn't matter either.  You need to distinguish between "We can't use IDEA
for commercial/licensing reasons" and "We refuse to consider IDEA for
ideological reasons".  I suspect instances of the former are pretty rare in
practice.  Give me some real-world examples where significant use of PGP was
affected by the current situation with IDEA, and show me how MUST NOT IDEA
would have fixed this.

Peter.

Date: Sat, 8 Mar 2003 16:06:18 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
To: [email-masked] (Peter Gutmann)
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

On Saturday, Mar 8, 2003, at 02:56 US/Eastern, Peter Gutmann wrote:

> "Jeroen C. van Gelderen" <[email-masked]> writes:
>> Unfortunately (at least) people who run a business are considered 
>> commercial
>> users and required to pay a licensing fee to the IDEA patent holder.
>
> In that case they can use an OpenPGP version (in fact I would hope 
> that a
> business isn't still using 10-year-old DOS-based software in their 
> commercial
> operations).  I would imagine that most people still sticking to PGP 
> 2.x are
> doing so because they've used it for years and are comfortable with 
> it, and by
> extension would be individual users who fall under the free-use terms. 
>  It
> seems like a bit of a non-issue to me - as Derek said, make it a MUST 
> NOT
> generate 2.x-style keys but SHOULD still support the message format, 
> that'll
> have the required effect.

How can my copy of OpenPGP support an IDEA-encrypted message if I am 
not allowed to use IDEA to decrypt it? Or are you saying that 
commercial users SHOULD pay the IDEA license fee because they SHOULD be 
able to handle IDEA-encrypted messages? That sucks in an open standard.

I can see how clients MAY support IDEA and thus MAY be required to pay 
money. That however sends a different message: get rid of your 
IDEA-encrypted messages or don't expect others to be able to read your 
messages.

I also think that at the very least PGP2-style encryption MUST not be 
used in addition to the requirement that PGP2 keys MUST NOT be 
generated.

If you do have a store of PGP2-encrypted messages you can easily 
re-encrypt them against a more current, OpenPGP compatible key. So that 
is not a reason to keep IDEA/PGP2 support.

That leaves us with PGP2 signatures and the implications of its removal 
on the existing web of trust. We're waiting for quantification in this 
department so that should be addressed later. But at the very least 
only verifying existing signatures seems a valid reason to keep parts 
of PGP2 support. The rest can be thrown out.

Either way I don't see why we should make an effort to support people 
who generate PGP2-anything these days. That is akin to equipping every 
new C-compiler with 8086 support because there might be people out 
there who refuse to ditch their PC-XTs.

Cheers,
-J

Date: Sat, 8 Mar 2003 20:56:22 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

"Jeroen C. van Gelderen" <[email-masked]> writes:
>On Saturday, Mar 8, 2003, at 01:07 US/Eastern, Peter Gutmann wrote:
>>I've been using it for years without paying royalties to Ascom, and so has
.>most of the rest of the PGP-using world.  It's only if you're selling it for
>>more than $10K (from memory) that you need to talk to Ascom.
>
>That would have had to be non-commercial use then[*]. 

Yup, it's for the (minute fraction of) email I receive that's encrypted.

>Unfortunately (at least) people who run a business are considered commercial
>users and required to pay a licensing fee to the IDEA patent holder.

In that case they can use an OpenPGP version (in fact I would hope that a
business isn't still using 10-year-old DOS-based software in their commercial
operations).  I would imagine that most people still sticking to PGP 2.x are
doing so because they've used it for years and are comfortable with it, and by
extension would be individual users who fall under the free-use terms.  It
seems like a bit of a non-issue to me - as Derek said, make it a MUST NOT
generate 2.x-style keys but SHOULD still support the message format, that'll
have the required effect.

Peter.

Date: Sat, 8 Mar 2003 02:36:48 -0500
Subject: Re: Further deprecating PGP2
Cc: [email-masked], [email-masked], [email-masked]
To: [email-masked] (Peter Gutmann)
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Saturday, Mar 8, 2003, at 01:07 US/Eastern, Peter Gutmann wrote:
> Werner Koch <[email-masked]> writes:
>> Implementing IDEA is trivial but as it is now, it is not possible to 
>> use any
>> software without paying royalities to Ascom.
>
> I've been using it for years without paying royalties to Ascom, and so 
> has
> most of the rest of the PGP-using world.  It's only if you're selling 
> it for
> more than $10K (from memory) that you need to talk to Ascom.

That would have had to be non-commercial use then[*]. Unfortunately (at 
least) people who run a business are considered commercial users and 
required to pay a licensing fee to the IDEA patent holder. This has 
nothing to do with the revenue you make off selling PGP software.

Unless things have changed of late, Werner's argument still holds. I'd 
add that a standard cannot be considered truly open when it is 
patent-encumbered. (Encumbered meaning that you need to pay for the 
patent license. CAST-5 obviously is not encumbered in this context.)

Please deprecate any and all uses of IDEA. And while we're at it, let's 
make the standard as lean as possible to increase the chances of 
interoperability. Another IPsec debacle should be avoided. (Though I 
have to admit that OpenPGP is easier to deploy than IPsec ;-p)

Cheers,
-J

[*] I mean, civil disobedience is encouraged, but hardly realistic for
     most commercial users.

Date: Sat, 8 Mar 2003 19:07:18 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Further deprecating PGP2
Cc: [email-masked]
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

>Implementing IDEA is trivial but as it is now, it is not possible to use any
>software without paying royalities to Ascom.

I've been using it for years without paying royalties to Ascom, and so has
most of the rest of the PGP-using world.  It's only if you're selling it for
more than $10K (from memory) that you need to talk to Ascom.

Peter.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Dash-escaping clarification
Date: Fri, 7 Mar 2003 22:46:39 -0500
Sender: [email-masked]

Subject: Re: Dash-escaping clarification

I didn't really generate the example to argue against David's suggestion.
In fact, I rather like it.  I provided it mostly for other implementors to
try out (and to see for myself what PGP and GPG would do).

The two most prevalent clients do accept it (almost... as David notes,
the GPG behavior on blank lines really feels like a bug, not a feature).

As for other things that might get chewed up by mail systems... I wonder
whether anything would rewrite MIME headers, were they embedded
in clearsigned text?  (I won't be generating a test case for this :-).

Date: Fri, 7 Mar 2003 22:17:23 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Minor clarification for fingerprint calculation
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 11.2 reads:

   A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
   Tag, followed by the two-octet packet length, followed by the
   entire Public Key packet starting with the version field.

This is a bit misleading, as the "one-octet Packet Tag" is not the
actual packet tag of the public key in question, but rather an old
style packet tag with the length-of-length set to 1 (for a two byte
length).  In other words: 0x99.

I've seen this line misunderstood a few times, with the resulting
incorrect fingerprints which were based off of the actual packet tag
of the public key.

I believe this line would be better as:

   A V4 fingerprint is the 160-bit SHA-1 hash of the octet
   0x99... (etc)

Note that the example following the text, as well as the references in
5.2.4 (for general hashing of a public key), and an additional
reference in 11.2 as part of the discussion of subkey fingerprints all
use 0x99.

David

Date: Fri, 7 Mar 2003 22:00:23 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 07, 2003 at 09:41:02PM -0500, Jeroen C. van Gelderen wrote:
> 
> On Friday, Mar 7, 2003, at 20:40 US/Eastern, David Shaw wrote:
> 
> >
> >On Fri, Mar 07, 2003 at 02:27:57PM -0500, Michael Young wrote:
> >
> >>- > ... A sentence saying something like "Any
> >>- > other line MAY be dash-escaped as well at the discretion of the
> >>- > sender" would be very helpful here.
> >>-
> >>- Sounds good, but as David points out, this may break existing 
> >>receivers.
> >>- See if yours can verify this.  (PGP6.5.3 silently accepts it.
> >>- GnuPG1.2.1 emits warnings on each line; it cannot verify this
> >>- signature, but if I remove the blank input line above, it can.)
> >
> >The point is that future receivers will know that such a thing is
> >possible.  They still don't have to support it - it's a MAY.
> 
> Erm, not the way I read it. A compliant implementation MAY generate 
> arbitrary dash escapes at the sender's discretion. A compliant receiver 
> MUST thus be able to handle this as it is a valid OpenPGP message. You 
> can't expect the sender to perform a capability check with the receiver 
> before sending the message.

Sorry, my error.  You are completely right.

> >It's hard to support something before it has been documented ;)
> 
> That definitely is true. But OpenPGP kinda documents the pre-existing 
> PGP. And it seems that the GnuPG people did test their implementation 
> against PGP which prompted allowing arbitrary escapes, albeit with a 
> warning.

Exactly.  There happens to be a minor detail of the GnuPG code so that
blank lines that are escaped are not accepted (i.e. a line with only
"- "), but that is easily remedied.

David

Date: Sat, 8 Mar 2003 03:42:28 +0100
From: Bodo Moeller <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, [email-masked], [email-masked]
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

On Fri, Mar 07, 2003 at 10:33:39AM -0800, Jon Callas wrote:

>> No.  PGP is not just about encryption, there's also signatures (in
>> particular, certification signatures).

> So we're no longer recommending against MD5? To my mind, MD5 is already a
> reason not to use V3.

The problem with MD5 is that it might become possible to find
collisions; but it doesn't look as if MD5 were not preimage-safe.

So there's nothing wrong about verifying *old* MD5-based signatures.
It's just not a good idea to generate *new* MD5-based signatures
unless you can be sure that the data to be signed has not specifically
been generated to exploit a collision in MD5.  And RFC 2440 already
warns that

   V3 keys SHOULD only be used for backward compatibility [...]

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Fri, 7 Mar 2003 21:41:02 -0500
Subject: Re: Dash-escaping clarification
Cc: [email-masked]
To: David Shaw <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Friday, Mar 7, 2003, at 20:40 US/Eastern, David Shaw wrote:

>
> On Fri, Mar 07, 2003 at 02:27:57PM -0500, Michael Young wrote:
>
>> - > ... A sentence saying something like "Any
>> - > other line MAY be dash-escaped as well at the discretion of the
>> - > sender" would be very helpful here.
>> -
>> - Sounds good, but as David points out, this may break existing 
>> receivers.
>> - See if yours can verify this.  (PGP6.5.3 silently accepts it.
>> - GnuPG1.2.1 emits warnings on each line; it cannot verify this
>> - signature, but if I remove the blank input line above, it can.)
>
> The point is that future receivers will know that such a thing is
> possible.  They still don't have to support it - it's a MAY.

Erm, not the way I read it. A compliant implementation MAY generate 
arbitrary dash escapes at the sender's discretion. A compliant receiver 
MUST thus be able to handle this as it is a valid OpenPGP message. You 
can't expect the sender to perform a capability check with the receiver 
before sending the message.

In any case, I'd like to make sure that if we allow the sending of 
arbitrary dash-escapes we also REQUIRE clients to be able to handle 
this. Otherwise we are introducing yet another complication in an 
already overly complex protocol. Even the x86 instruction set looks 
clean compared to the current OpenPGP spec. (And, yes, that is a vote 
against v3 support.)

Come to think of it, in good PGP tradition, we could REQUIRE acceptance 
now and add MAY arbitrarily escape in a year or so ;)

> It's hard to support something before it has been documented ;)

That definitely is true. But OpenPGP kinda documents the pre-existing 
PGP. And it seems that the GnuPG people did test their implementation 
against PGP which prompted allowing arbitrary escapes, albeit with a 
warning.

Cheers,
-J

Date: Fri, 7 Mar 2003 21:35:39 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Minor typo change
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I made an error when writing up the user attribute packets.  In
section 5.2.4 ("Computing Signatures"), there is a sentence:

   A V4 certification hashes the constant 0xb4 for user ID
   certifications or the constant 0xd1 for User Attribute
   certifications (which are old-style packet headers with the
   length-of-length set to zero), followed by a four-octet number
   giving the length of the user ID or User Attribute data, and then
   the User ID or User Attribute data.

0xd1 is of course not an old-style packet header.

David

Date: Fri, 7 Mar 2003 21:14:52 -0500
Subject: Re: Dash-escaping clarification
Cc: [email-masked]
To: Adam Back <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Friday, Mar 7, 2003, at 20:53 US/Eastern, Adam Back wrote:
> See Michael Young's example: doing so breaks existing otherwise
> compliant implementations.

They probably can be fixed. And since OpenPGP isn't a finished standard 
yet this might be less of a problem in practice than it appears on 
paper.

> 'From ' is pretty much the only thing interesting to protect in an
> email message, as it is a separator between email messages.

It is also a protocol-specific hack. I strongly support simpler 
solutions if they achieve the same purpose. Allowing arbitrary lines to 
be escaped is simpler. OpenPGP too complex as-is.

> The '-' escape was just a way to protect nested signatures etc to
> avoid confusing the parser of the outer signatures.
>
> The rule's been that way since at least 1992, and I haven't seen any
> new chars needing quoting.  So it's survived the test of time.

That doesn't mean that a simpler rule isn't a better idea. In fact, 
ever since 1992, PGP has allowed for arbitrary lines to be escaped. So 
one could argue that the current OpenPGP standard is too restrictive.

At the very least we can argue that the OpenPGP way of defining 
escaping isn't sufficiently obvious that PGP get it wrong.

Cheers,
-J

Date: Fri, 7 Mar 2003 21:00:28 -0500
Subject: Re: Dash-escaping clarification
Cc: [email-masked]
To: Adam Back <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

On Friday, Mar 7, 2003, at 17:16 US/Eastern, Adam Back wrote:

>
> Hmm I don't think it would be a good idea to allow dash-escaping of
> literally anything because then you can't reverse the transformation
> and '- ' is commonly used for bullet points where as the other cases
> ----- separated nested PGP signatures and other content types are not
> common, and 'From ' is a prexisting common exception.
>
> Isn't it rather just:
>
> - dash escape nested -----BEGIN PGP MESSAGE----- (et al)
> - dash escape From

I think the idea has always been to escape all dashes so that the 
receiver can indiscriminately remove the <dash><space> prefix from 
every line in a received message. It is precisely this approach which 
makes it possible to allow arbitrary sentences to be dash-escaped 
*without* the transformation being irreversible.

Cheers,
-J

Date: Sat, 8 Mar 2003 01:53:03 +0000
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: Adam Back <[email-masked]>
Subject: Re: Dash-escaping clarification
Sender: [email-masked]

See Michael Young's example: doing so breaks existing otherwise
compliant implementations.

'From ' is pretty much the only thing interesting to protect in an
email message, as it is a separator between email messages.

The '-' escape was just a way to protect nested signatures etc to
avoid confusing the parser of the outer signatures.

The rule's been that way since at least 1992, and I haven't seen any
new chars needing quoting.  So it's survived the test of time.

Adam

On Fri, Mar 07, 2003 at 07:39:58PM -0500, David Shaw wrote:
> > - dash escape leading '-'
> > - dash escape 'From '
> > 
> > and that's it.
> 
> I disagree.  Tomorrow will bring some other thing that needs to be
> protected against modification.  A single rule that "anything may be
> dash-escaped" is simpler and more general than two specific rules.
> 
> David

Date: Fri, 7 Mar 2003 20:40:58 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 07, 2003 at 02:27:57PM -0500, Michael Young wrote:

> - > ... A sentence saying something like "Any
> - > other line MAY be dash-escaped as well at the discretion of the
> - > sender" would be very helpful here.
> - 
> - Sounds good, but as David points out, this may break existing receivers.
> - See if yours can verify this.  (PGP6.5.3 silently accepts it.
> - GnuPG1.2.1 emits warnings on each line; it cannot verify this
> - signature, but if I remove the blank input line above, it can.)

The point is that future receivers will know that such a thing is
possible.  They still don't have to support it - it's a MAY.

It's hard to support something before it has been documented ;)

David

Date: Fri, 7 Mar 2003 19:39:58 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 07, 2003 at 10:25:36PM +0000, Adam Back wrote:
> 
> Let me modify that.  I just tried a few combinations with PGP and it
> dash escapes leading '-', and 'From ' but pretty much nothing else.
> 
> So to describe existing behavior we could say:
> 
> - dash escape leading '-'
> - dash escape 'From '
> 
> and that's it.

I disagree.  Tomorrow will bring some other thing that needs to be
protected against modification.  A single rule that "anything may be
dash-escaped" is simpler and more general than two specific rules.

David

Date: Fri, 7 Mar 2003 19:38:20 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 07, 2003 at 10:16:45PM +0000, Adam Back wrote:
> 
> Hmm I don't think it would be a good idea to allow dash-escaping of
> literally anything because then you can't reverse the transformation
> and '- ' is commonly used for bullet points where as the other cases
> ----- separated nested PGP signatures and other content types are not
> common, and 'From ' is a prexisting common exception.

I don't see how there would be a problem in reversing the
transformation.

- bullet point
becomes
- - bullet point
and reverses back to
- bullet point

random text
becomes
- random text
and reverses back to
random text

David

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 07 Mar 2003 21:52:57 +0100
Sender: [email-masked]

On Thu, 06 Mar 2003 21:31:44 -0800, Jon Callas said:

> All right -- here's what I'm hearing -- get rid of MD2, Haval, and DW-SHA.
> DW-SHA is not the same thing as SHA-256/384/512, sometimes called SHA-2, but
> not by NIST.

And TIGER.

To: "OpenPGP" <[email-masked]>
Cc: "M. Drew Streib" <[email-masked]>
Subject: Re: Further deprecating PGP2
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 07 Mar 2003 21:50:01 +0100
Sender: [email-masked]

On Fri, 7 Mar 2003 12:22:09 -0500, Michael Young said:

> My guess is that this is a reaction to IDEA's patent encumberment.

Sure.  Implementing IDEA is trivial but as it is now, it is not
possible to use any software without paying royalities to Ascom.  Also
IDEA is kind of optional in OpenPGP - due to the use of v3 keys it is
practically a must-have. 

I had the same thing in mind as Bodo when I asked for removing IDEA:
There are still a lot of v3 keys with valuable signatures (I have
signed countless v3 keys using my v4 key) it might change the WoT when
we entirely ban v3 keys.  Deprecating IDEA might have the effect, that
only key signatures are to be used.

So, lets ask Drew Streib to run a key analysis with skipped v3 keys
and compare it to the full analysis.

Depending on the result, it would be perfectly okay for me to either
drop v3 or only allow v3 for key signatures.

Salam-Shalom,

   Werner

Date: Fri, 7 Mar 2003 22:25:36 +0000
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: Adam Back <[email-masked]>
Subject: Re: Dash-escaping clarification
Sender: [email-masked]

Let me modify that.  I just tried a few combinations with PGP and it
dash escapes leading '-', and 'From ' but pretty much nothing else.

So to describe existing behavior we could say:

- dash escape leading '-'
- dash escape 'From '

and that's it.

Adam

On Fri, Mar 07, 2003 at 10:16:45PM +0000, Adam Back wrote:
> Hmm I don't think it would be a good idea to allow dash-escaping of
> literally anything because then you can't reverse the transformation
> and '- ' is commonly used for bullet points where as the other cases
> ----- separated nested PGP signatures and other content types are not
> common, and 'From ' is a prexisting common exception.
> 
> Isn't it rather just:
> 
> - dash escape nested -----BEGIN PGP MESSAGE----- (et al)
> - dash escape From
> 
> Adam

Date: Fri, 7 Mar 2003 22:16:45 +0000
From: Adam Back <[email-masked]>
To: [email-masked]
Cc: Adam Back <[email-masked]>
Subject: Re: Dash-escaping clarification
Sender: [email-masked]

Hmm I don't think it would be a good idea to allow dash-escaping of
literally anything because then you can't reverse the transformation
and '- ' is commonly used for bullet points where as the other cases
----- separated nested PGP signatures and other content types are not
common, and 'From ' is a prexisting common exception.

Isn't it rather just:

- dash escape nested -----BEGIN PGP MESSAGE----- (et al)
- dash escape From

Adam

On Fri, Mar 07, 2003 at 08:46:34AM -0500, David Shaw wrote:
> 
> Section 7.1 (Dash-Escaped Text) of bis-07 says, in part, that
> dash-escaped text is "the ordinary cleartext where every line starting
> with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and
> space ' ' (0x20)."
> 
> Since the most common use of dash-escaped text is in email, both PGP
> and GnuPG (by default) also dash-escape lines starting with the word
> "From " (with the space).  This is for the usual mbox-inspired
> reasons.  If the "From " line isn't escaped, then some downstream mail
> system may escape it, thus breaking the signature.
> 
> Nothing in the draft seems to discourage dash-escaping more than just
> the lines beginning with a dash.  Still, I am concerned with the
> receiving side not knowing that these other lines may be escaped as
> well (they may match on a dash-space-dash at the beginning of the
> line, rather than dash-space).  A sentence saying something like "Any
> other line MAY be dash-escaped as well at the discretion of the
> sender" would be very helpful here.
> 
> David

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 07 Mar 2003 21:52:57 +0100
Sender: [email-masked]

On Thu, 06 Mar 2003 21:31:44 -0800, Jon Callas said:

> All right -- here's what I'm hearing -- get rid of MD2, Haval, and DW-SHA.
> DW-SHA is not the same thing as SHA-256/384/512, sometimes called SHA-2, but
> not by NIST.

And TIGER.

To: "OpenPGP" <[email-masked]>
Cc: "M. Drew Streib" <[email-masked]>
Subject: Re: Further deprecating PGP2
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 07 Mar 2003 21:50:01 +0100
Sender: [email-masked]

On Fri, 7 Mar 2003 12:22:09 -0500, Michael Young said:

> My guess is that this is a reaction to IDEA's patent encumberment.

Sure.  Implementing IDEA is trivial but as it is now, it is not
possible to use any software without paying royalities to Ascom.  Also
IDEA is kind of optional in OpenPGP - due to the use of v3 keys it is
practically a must-have. 

I had the same thing in mind as Bodo when I asked for removing IDEA:
There are still a lot of v3 keys with valuable signatures (I have
signed countless v3 keys using my v4 key) it might change the WoT when
we entirely ban v3 keys.  Deprecating IDEA might have the effect, that
only key signatures are to be used.

So, lets ask Drew Streib to run a key analysis with skipped v3 keys
and compare it to the full analysis.

Depending on the result, it would be perfectly okay for me to either
drop v3 or only allow v3 for key signatures.

Salam-Shalom,

   Werner

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Dash-escaping clarification
Date: Fri, 7 Mar 2003 14:27:57 -0500
Sender: [email-masked]

- > ... A sentence saying something like "Any
- > other line MAY be dash-escaped as well at the discretion of the
- > sender" would be very helpful here.
- 
- Sounds good, but as David points out, this may break existing receivers.
- See if yours can verify this.  (PGP6.5.3 silently accepts it.
- GnuPG1.2.1 emits warnings on each line; it cannot verify this
- signature, but if I remove the blank input line above, it can.)

Date: Fri, 7 Mar 2003 11:24:21 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Bodo Moeller <[email-masked]>
Cc: Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

On Fri, 7 Mar 2003, Bodo Moeller wrote:

> > Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.
>
> No.  PGP is not just about encryption, there's also signatures (in
> particular, certification signatures).

I do not think the web of trust would be significantly altered if V3 keys
were depricated. (I'd like to see Drew Streib's key analysis run with the
v3 keys excluded to test this theory). More important to the users is
individual trust changes. Perhaps this could be addressed by stating that
key certifications "MAY" but "SHOULD NOT" be v3 format (and reference RFC
1991)? (Am I correct in assuming that v3 as described in OpenPGP is
identical to v3 in 1991?)

I'd also be happy just cutting the v3 web loose.

Date: Fri, 07 Mar 2003 10:33:39 -0800
Subject: Re: meeting in San Francisco?
From: Jon Callas <[email-masked]>
To: Bodo Moeller <[email-masked]>
CC: Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/7/03 5:45 AM, "Bodo Moeller" <[email-masked]>
wrote:

> No.  PGP is not just about encryption, there's also signatures (in
> particular, certification signatures).
> 

So we're no longer recommending against MD5? To my mind, MD5 is already a
reason not to use V3.

    Jon

Date: Fri, 07 Mar 2003 10:33:12 -0800
Subject: Re: Dash-escaping clarification
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/7/03 5:46 AM, "David Shaw" <[email-masked]> wrote:

Added in for bis08.

    Jon

> 
> Section 7.1 (Dash-Escaped Text) of bis-07 says, in part, that
> dash-escaped text is "the ordinary cleartext where every line starting
> with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and
> space ' ' (0x20)."
> 
> Since the most common use of dash-escaped text is in email, both PGP
> and GnuPG (by default) also dash-escape lines starting with the word
> "From " (with the space).  This is for the usual mbox-inspired
> reasons.  If the "From " line isn't escaped, then some downstream mail
> system may escape it, thus breaking the signature.
> 
> Nothing in the draft seems to discourage dash-escaping more than just
> the lines beginning with a dash.  Still, I am concerned with the
> receiving side not knowing that these other lines may be escaped as
> well (they may match on a dash-space-dash at the beginning of the
> line, rather than dash-space).  A sentence saying something like "Any
> other line MAY be dash-escaped as well at the discretion of the
> sender" would be very helpful here.
> 
> David
> 

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Further deprecating PGP2 (was: Re: meeting in San Francisco?)
Date: Fri, 7 Mar 2003 12:22:09 -0500
Sender: [email-masked]

From: "Werner Koch" <[email-masked]>
> The real problem is the continued use of IDEA, especially to protect
> secret keys.  A strong word that the use of IDEA is deprecated would
> be helpful.

My guess is that this is a reaction to IDEA's patent encumberment.
If so, I disagree with Werner.  The spec should certainly point
out the patent issue, but that shouldn't be grounds for deprecation.
Those using v4 keys can express their preference for other
algorithms.  Most v3 key users are stuck with IDEA anyway, so
marking it deprecated won't sway them.

(If Werner's talking about the non-S2K protection of secret
keys, that is already described as deprecated.)

Or, perhaps there has been a recent vulnerability discovered
in IDEA that I've missed.  If so, could someone provide a reference?

From: "Jon Callas" <[email-masked]>
> Personally, I'd love to deprecate PGP 2.6. Almost all the interoperability
> problems we have revolve around it.

Are you talking about merely marking it deprecated, or are you
contemplating removing some of the PGP2 interoperability
discussion?

Three are lots of v3-based signatures out there.  They're a major
contributor to the "web of trust".  I think it's important to
retain at least the key and signature format material.

The PGP2 handling of symmetric-key message encryption is already
marked as deprecated.

I'd be happy to see more of the PGP2 idiosyncracies moved out of the
mainline into an interoperability section, but I think it would be a
great disservice to drop them entirely.

Date: Fri,  7 Mar 2003 08:38:49 -0800
To: [email-masked]
Cc: 
Subject: Re: meeting in San Francisco? (v3 keys // IDEA)
From: [email-masked]
Sender: [email-masked]

On Thu, 06 Mar 2003 14:37:08 -0800 Jon Callas <[email-masked]> wrote:
>
>On 3/6/03 2:10 AM, "Werner Koch" <[email-masked]> wrote:
>
>> I don't think that it is really required to deprecate v3 keys. 
..
>> The real problem is the continued use of IDEA, especially to protect
>> secret keys.  A strong word that the use of IDEA is deprecated 
>would
>> be helpful.
>
>It is my opinion that deprecating IDEA (which I would be happy to 
>do) is
>about the same as deprecating V3 keys.
>
>The reason I say that is that the only reason for a V3 key is to
>interoperate with PGP 2.6. PGP 2.6 has only IDEA.

many remailers use Disasty's multi version of pgp 2.6,
which accepts all algorithms and hashes,
but still requires a v3 key for the encryption,
and is quite compatible with GnuPG, even without IDEA,
except that, as WK says, someone importing a v3 key into GnuPG still needs IDEA to unlock the secret key.

Disastry's multi version of 2.6, allows v3 keys to be generated easily,
that don't require IDEA 

'deprecation'of IDEA, to point out that there are other 'advanced and better / patent-free' ways to do things, but still allow v3 keys to be used, seems more tolerant, and allows compatibility, even if inconvenient.

with Respect,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2 

Big $$$ to be made with the HushMail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Fri, 7 Mar 2003 08:46:34 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Dash-escaping clarification
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 7.1 (Dash-Escaped Text) of bis-07 says, in part, that
dash-escaped text is "the ordinary cleartext where every line starting
with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and
space ' ' (0x20)."

Since the most common use of dash-escaped text is in email, both PGP
and GnuPG (by default) also dash-escape lines starting with the word
"From " (with the space).  This is for the usual mbox-inspired
reasons.  If the "From " line isn't escaped, then some downstream mail
system may escape it, thus breaking the signature.

Nothing in the draft seems to discourage dash-escaping more than just
the lines beginning with a dash.  Still, I am concerned with the
receiving side not knowing that these other lines may be escaped as
well (they may match on a dash-space-dash at the beginning of the
line, rather than dash-space).  A sentence saying something like "Any
other line MAY be dash-escaped as well at the discretion of the
sender" would be very helpful here.

David

Date: Fri, 7 Mar 2003 14:45:41 +0100
From: Bodo Moeller <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, [email-masked], [email-masked]
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

On Thu, Mar 06, 2003 at 02:37:08PM -0800, Jon Callas wrote:

> It is my opinion that deprecating IDEA (which I would be happy to do) is
> about the same as deprecating V3 keys.
> 
> The reason I say that is that the only reason for a V3 key is to
> interoperate with PGP 2.6. PGP 2.6 has only IDEA.
> 
> Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.

No.  PGP is not just about encryption, there's also signatures (in
particular, certification signatures).

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Thu, 06 Mar 2003 21:31:44 -0800
Subject: Re: Settling the TIGER question
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/6/03 4:50 PM, "Len Sassaman" <[email-masked]> wrote:

> Yes, definitely leave SHA2 in. (I think I was one of the people who pushed
> to have it added.) "SHA2", or rather "SHA256, SHA384, and SHA512" are hash
> algorithm ids 8-10.
> 
> What I'm refering to above is the hash algorithm id 4 -- "double-width
> SHA".
> 
> I would like to see hashes 1, 2, 3, 8, 9, 10 remain, and if possible,
> hashes 4, 5, 6, and 7 removed.

All right -- here's what I'm hearing -- get rid of MD2, Haval, and DW-SHA.
DW-SHA is not the same thing as SHA-256/384/512, sometimes called SHA-2, but
not by NIST.

    Jon

Date: Thu, 6 Mar 2003 16:50:48 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: David Shaw <[email-masked]>, Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
Sender: [email-masked]

On 6 Mar 2003, Derek Atkins wrote:

> > Yes. And double-width SHA as well. Is there a reason for MD2?
>
> SHA2 might be interesting in the not-to-distant future; I'd recommend
> leaving it in.

Yes, definitely leave SHA2 in. (I think I was one of the people who pushed
to have it added.) "SHA2", or rather "SHA256, SHA384, and SHA512" are hash
algorithm ids 8-10.

What I'm refering to above is the hash algorithm id 4 -- "double-width
SHA".

I would like to see hashes 1, 2, 3, 8, 9, 10 remain, and if possible,
hashes 4, 5, 6, and 7 removed.

To: Len Sassaman <[email-masked]>
Cc: David Shaw <[email-masked]>, Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Settling the TIGER question
Date: 06 Mar 2003 19:43:42 -0500
Lines: 18
Sender: [email-masked]

Len Sassaman <[email-masked]> writes:

> On Thu, 6 Mar 2003, David Shaw wrote:
> 
> > If TIGER/192 is removed, perhaps it would be good if HAVAL-5-160 was
> > removed as well, for the same reasons.
> 
> Yes. And double-width SHA as well. Is there a reason for MD2?

SHA2 might be interesting in the not-to-distant future; I'd recommend
leaving it in.

-derek

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

Date: Thu, 6 Mar 2003 19:06:08 -0500
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
Mail-Followup-To: Len Sassaman <[email-masked]>, Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, Mar 06, 2003 at 03:56:30PM -0800, Len Sassaman wrote:
> On Thu, 6 Mar 2003, David Shaw wrote:
> 
> > If TIGER/192 is removed, perhaps it would be good if HAVAL-5-160 was
> > removed as well, for the same reasons.
> 
> Yes. And double-width SHA as well. Is there a reason for MD2?

I've seen it implemented here and there in OpenPGP libraries.  I doubt
it gets very wide use as neither GnuPG or (so far as I know) PGP
implement it.

David

Date: Thu, 6 Mar 2003 15:56:30 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: David Shaw <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
Sender: [email-masked]

On Thu, 6 Mar 2003, David Shaw wrote:

> If TIGER/192 is removed, perhaps it would be good if HAVAL-5-160 was
> removed as well, for the same reasons.

Yes. And double-width SHA as well. Is there a reason for MD2?

Date: Thu, 6 Mar 2003 18:46:48 -0500
From: David Shaw <[email-masked]>
To: Len Sassaman <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
Mail-Followup-To: Len Sassaman <[email-masked]>, Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, Mar 06, 2003 at 03:18:25PM -0800, Len Sassaman wrote:
> 
> On Thu, 6 Mar 2003, Jon Callas wrote:
> 
> > Does anyone object to my removing TIGER/192, in the interests of less is
> > more?
> 
> Please do.

If TIGER/192 is removed, perhaps it would be good if HAVAL-5-160 was
removed as well, for the same reasons.

David

Date: Thu, 6 Mar 2003 15:18:25 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Settling the TIGER question
Sender: [email-masked]

On Thu, 6 Mar 2003, Jon Callas wrote:

> Does anyone object to my removing TIGER/192, in the interests of less is
> more?

Please do.

Date: Thu, 6 Mar 2003 23:10:59 +0000
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: OpenPGP <[email-masked]>, [email-masked]
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

I agree, please do not take v3 keys out.

Adam

On Thu, Mar 06, 2003 at 05:47:23PM -0500, Derek Atkins wrote:
> 
> Hey, I still use a v3 key...  And I have a LOT of mail encrypted with
> it.  I would highly object to taking compat out of the spec.
> 
> Adding verbiage to the extent of "you MUST NOT generate a v3 key" is
> fine with me, however implementation SHOULD (if not MUST) be able to
> parse a v3 key.
> 
> -derek

Date: Thu, 06 Mar 2003 15:03:47 -0800
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: informal meeting in san francisco
Sender: [email-masked]

I think we should attempt to have an informal meeting
(plus or minus appropriate IETF behavior with regards to
minutes-taking, etc.)  Anyone else interested?  Any specific
day/time that people would find convienient?

Date: Thu, 6 Mar 2003 14:54:28 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

On 6 Mar 2003, Derek Atkins wrote:

> Hey, I still use a v3 key...  And I have a LOT of mail encrypted with
> it.  I would highly object to taking compat out of the spec.

Then use an implementation that speaks both RFC 1991 and OpenPGP. Don't
add cruft into OpenPGP because you have an emotional attachment to a dead
key format.

> Adding verbiage to the extent of "you MUST NOT generate a v3 key" is
> fine with me, however implementation SHOULD (if not MUST) be able to
> parse a v3 key.

All of this is beside the point. "PGP Desktop", or whatever it is being
called today, could implement both RFC 1991 support, and OpenPGP support,
and not violate OpenPGP even if v3 keys weren't in the spec. It's just
doing two different protocols. (Just like OpenPGP says nothing about disk
encryption, but it's in PGP Desktop.)

The only thing that would have to change, functionally, is that people may
have to start encrypting messages twice if they are to a large number of
users: once for the people with v3 keys, and once for the people with v4
keys. Unfortunately, that is the state of the world now in some cases,
where IDEA is the cipher for v3, and 3DES is the cipher for v4. Not to
mention the v3 interop bugs in GnuPG, which, while resolved now, still
linger in old versions. Better that the protocol not try to handle these
cases, and instead leave it up to the application. (This change could be
implemented invisibly to the user.)

--Len.

To: Len Sassaman <[email-masked]>
Cc: Jon Callas <[email-masked]>, Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: meeting in San Francisco?
Date: 06 Mar 2003 17:47:23 -0500
Lines: 39
Sender: [email-masked]

Hey, I still use a v3 key...  And I have a LOT of mail encrypted with
it.  I would highly object to taking compat out of the spec.

Adding verbiage to the extent of "you MUST NOT generate a v3 key" is
fine with me, however implementation SHOULD (if not MUST) be able to
parse a v3 key.

-derek

Len Sassaman <[email-masked]> writes:

> On Thu, 6 Mar 2003, Jon Callas wrote:
> 
> > It is my opinion that deprecating IDEA (which I would be happy to do) is
> > about the same as deprecating V3 keys.
> 
> Agreed.
> 
> > The reason I say that is that the only reason for a V3 key is to
> > interoperate with PGP 2.6. PGP 2.6 has only IDEA.
> >
> > Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.
> >
> > Personally, I'd love to deprecate PGP 2.6. Almost all the interoperability
> > problems we have revolve around it.
> 
> I fully agree with Jon. As long as v3 is in the spec, expect to see new
> implementations including it. There needs to be very strong language in
> the spec that says v3 should not be implemented any further. Or, remove it
> from the spec entirely and make it its own document.
> 
> I think it was a mistake from the start to offer v3 - v4 interoperability.
> It's now time to kill v3 and eliminate a large body of interop problems.
> 

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

Date: Thu, 6 Mar 2003 14:42:13 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>
Subject: Re: meeting in San Francisco?
Sender: [email-masked]

On Thu, 6 Mar 2003, Jon Callas wrote:

> It is my opinion that deprecating IDEA (which I would be happy to do) is
> about the same as deprecating V3 keys.

Agreed.

> The reason I say that is that the only reason for a V3 key is to
> interoperate with PGP 2.6. PGP 2.6 has only IDEA.
>
> Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.
>
> Personally, I'd love to deprecate PGP 2.6. Almost all the interoperability
> problems we have revolve around it.

I fully agree with Jon. As long as v3 is in the spec, expect to see new
implementations including it. There needs to be very strong language in
the spec that says v3 should not be implemented any further. Or, remove it
from the spec entirely and make it its own document.

I think it was a mistake from the start to offer v3 - v4 interoperability.
It's now time to kill v3 and eliminate a large body of interop problems.

Date: Thu, 06 Mar 2003 14:37:08 -0800
Subject: Re: meeting in San Francisco?
From: Jon Callas <[email-masked]>
To: Werner Koch <[email-masked]>, Rodney Thayer <[email-masked]>
CC: Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/6/03 2:10 AM, "Werner Koch" <[email-masked]> wrote:

> I don't think that it is really required to deprecate v3 keys.  Almost
> all applications do create v4 keys and it should be up to the
> implementor to support them or not.  There are still enough v3 keys
> alive so that implementors must still handle keyIDs and fingerprints
> separately.
> 
> The real problem is the continued use of IDEA, especially to protect
> secret keys.  A strong word that the use of IDEA is deprecated would
> be helpful.

It is my opinion that deprecating IDEA (which I would be happy to do) is
about the same as deprecating V3 keys.

The reason I say that is that the only reason for a V3 key is to
interoperate with PGP 2.6. PGP 2.6 has only IDEA.

Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.

Personally, I'd love to deprecate PGP 2.6. Almost all the interoperability
problems we have revolve around it.

    Jon

Date: Thu, 06 Mar 2003 12:25:04 -0800
Subject: Re: Settling the TIGER question
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 3/6/03 6:56 AM, "David Shaw" <[email-masked]> wrote:

> 
> Now that bis-07 is out, I'd like to get a TIGER/192 issue settled.
> 
> First, to be clear: my intent is NOT to question to use of TIGER, to
> suggest other hashes are better, or anything of the like.
> 
> Bis-07, in section 9.4 reserves algorithm number 6 for TIGER/192, and
> section 12.7 elaborates that it is reserved because it does not have
> an OID.  Since that was written, TIGER/192 has been assigned an OID :
> 1.3.6.1.4.1.11591.12.2
> 
> I know there have been some comments about dropping TIGER altogether
> from the standard.  I have no strong feelings about this either way.
> However, if TIGER is going to remain in the standard, then in the
> interest of accuracy, we should at least give the OID.
> 
> David
> 

Does anyone object to my removing TIGER/192, in the interests of less is
more?

    Jon

Date: Thu, 6 Mar 2003 09:56:57 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Settling the TIGER question
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Now that bis-07 is out, I'd like to get a TIGER/192 issue settled.

First, to be clear: my intent is NOT to question to use of TIGER, to
suggest other hashes are better, or anything of the like.

Bis-07, in section 9.4 reserves algorithm number 6 for TIGER/192, and
section 12.7 elaborates that it is reserved because it does not have
an OID.  Since that was written, TIGER/192 has been assigned an OID :
1.3.6.1.4.1.11591.12.2

I know there have been some comments about dropping TIGER altogether
from the standard.  I have no strong feelings about this either way.
However, if TIGER is going to remain in the standard, then in the
interest of accuracy, we should at least give the OID.

David

Date: Thu, 6 Mar 2003 15:53:30 +0100
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt
Sender: [email-masked]

On Thu, Mar 06, 2003 at 06:24:14AM -0500, [email-masked] wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt

5.2.3.3. Notes on Self-Signatures

[...]

   Revoking a self-signature or allowing it to expire has a semantic
   meaning that varies with the signature type. Revoking the
   self-signature on a user ID effectively retires that user name. The
   self-signature is a statement, "My name X is tied to my signing key
   K" and is corroborated by other users' certifications. If another
   user revokes their certification, they are effectively saying that
   they no longer believe that name and that key are tied together.
   Similarly, if the user themselves revokes their self-signature, it
   means the user no longer goes by that name, no longer has that email
   address, etc. Revoking a binding signature effectively retires that
   subkey. Revoking a direct-key signature cancels that signature.
   Please see the "Reason for Revocation" subpacket below for more
   relevant detail.

[...]
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

What about appending a new section after 5.2.3.3 as follows to ensure
that there is a way to express key expiry such that keys cannot be
un-expired by attackers later (see the threads at
     http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
and finally
     http://www.imc.org/ietf-openpgp/mail-archive/msg04220.html
):

5.2.3.?.  Notes on certification signatures

   While the version 3 public key packet format includes a field for
   stating key expiry, the version 4 public key packet format does
   not: key expiry is now expressed via the optional key expiration
   time subpacket in signature packets instead.  Thus, unlike with the
   version 3 public key packet format, certification signatures do not
   automatically cover the key expiration time.

   This is a feature -- it makes it possible to issue keys with short
   life-time that can be extended later; as key expiry does not
   automatically carry over into certifications, re-certification can
   be avoided.  But for the same reasons, it is a problem when handled
   naively -- just as well as the legitimate key owner, an adversary
   who somehow obtains the private key can bring supposedly expired
   keys back to life.

   To avoid the potential problems without losing the feature, the
   following procedures should befollowed when certifying a user ID:

   Any validity period defined in direct-key self-signatures for the
   key to be certified is just used to determine whether the key is
   currently valid (at time of certification).  Such validity periods
   do not automatically carry over into certifications.

   Key expiration that is intended to be final (such that the key
   cannot be un-expired later) should be set in certification
   self-signatures, not in direct-key self-signatures.

   When certifying someone else's user ID, the currently valid
   certification self-signatures for the user ID/public key
   combination to be certified should be examined for key expiration
   times.  By default, the new certification should have signature
   validity extending no further into the future than the maximum key
   validity that has been found in these certification
   self-signatures (if there is a valid certification self-signature
   according to which the key never expires, then the new
   certification signature need not expire either).  Note that this is
   just a reasonably safe default, no fixed rule -- the key owner
   might inform the certifying party of an appropriate expiry date via
   out-of-band means.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-07.txt
Date: Thu, 06 Mar 2003 06:24:14 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-07.txt
	Pages		: 71
	Date		: 2003-3-5
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: Rodney Thayer <[email-masked]>
Cc: Derek Atkins <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: meeting in San Francisco?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 06 Mar 2003 11:10:25 +0100
Sender: [email-masked]

On Wed, 05 Mar 2003 16:29:28 -0800, Rodney Thayer said:

> - deprecating pgp 2 keys.  I don't happen to like the idea myself, but lots of
> people (Len?) have strong opinions about this and therefore I think
> the WG should
> discuss it, at least a little bit, at least to form a "wg opinion".

I don't think that it is really required to deprecate v3 keys.  Almost
all applications do create v4 keys and it should be up to the
implementor to support them or not.  There are still enough v3 keys
alive so that implementors must still handle keyIDs and fingerprints
separately.

The real problem is the continued use of IDEA, especially to protect
secret keys.  A strong word that the use of IDEA is deprecated would
be helpful.

Shalom-Salam,

   Werner

Date: Wed, 5 Mar 2003 22:26:04 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Deprecating old keys (was Re: meeting in San Francisco?)
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Wed, Mar 05, 2003 at 06:07:28PM -0800, Jon Callas wrote:

> The easiest of all (assuming that there's WG agreement) is
> deprecating old keys. Get rough consensus, and it's about a
> half-hour work from me.

While I have frequently complained to myself about some odd corner
case involving v3 keys, and life would undoubtedly be simpler without
them, I do wonder what practical difference deprecating v3 keys would
have.

GnuPG already refuses to generate new v3 keys, and PGP asks the user
to reconsider before making one.  I doubt any OpenPGP program could
stop supporting existing v3 keys any time soon.  Last I looked, over
90% of the keys on the public keyservers were v4.  I think the natural
evolution of OpenPGP has already deprecated v3 keys for us..

David

Date: Wed, 5 Mar 2003 22:14:29 -0500
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: HKP (was Re: meeting in San Francisco?)
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Wed, Mar 05, 2003 at 06:07:28PM -0800, Jon Callas wrote:

> There's nothing that stops Ben's PFS draft from becoming an
> informational RFC. There's little that stops that from becoming
> standards track -- this group merely has to agree that it's in our
> domain. Obviously, it'd be optional, but.

Speaking of domains - I have documented the HTTP keyserver protocol
with a few extensions to handle some things that were not needed back
when the protocol was created.  I was planning on pushing it towards
an informational RFC, but if the folks here think it would be better
as standards track, then I can certainly do that.

David

Date: Wed, 05 Mar 2003 18:07:28 -0800
Subject: Re: meeting in San Francisco?
From: Jon Callas <[email-masked]>
To: Rodney Thayer <[email-masked]>, Derek Atkins <[email-masked]>
CC: OpenPGP <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 3/5/03 4:29 PM, "Rodney Thayer" <[email-masked]> wrote:

> - draft 07bis or 08 or whatever it's at (Jon?  does this make sense?)
> 

Bis-07 was sent to the editor last weekend.

> - the key server protocol activity that the keyserver-folks and Peter Gutmann
> have been discussing.  I think I'm in the midst of volunteering to do a short
> presentation on that, so I would like to ask for a 15 minute slot
> 
> - ben laurie's perfect forward secrecy draft.  which he kept trying to bring
> up as a discussion topic.  I'm not claiming it's perfect or anything but I
> think
> we should at least discuss it.  I'm sure we can rope someone into doing
> a short presentation on this.
> 
> - deprecating pgp 2 keys.  I don't happen to like the idea myself, but lots of
> people (Len?) have strong opinions about this and therefore I think the WG
> should
> discuss it, at least a little bit, at least to form a "wg opinion".

IETF discussions are open to anyone who wants to discuss them, really.

All three of those things are reasonable to discuss, and so the relevant
persons should discuss them.

Lots of people say to me "The WG should discuss X." My standard response is,
"What a good idea, bring it up." Very few people do that. It is my opinion
that someone who is unwilling to commit to a few email messages doesn't
*really* want to discuss it, they want to complain about how the WG doesn't
want to do their cool thing. That's fine, too. I sometimes like to go off on
how if I were King, the world would be so much better, too.

There's nothing that stops Ben's PFS draft from becoming an informational
RFC. There's little that stops that from becoming standards track -- this
group merely has to agree that it's in our domain. Obviously, it'd be
optional, but.

The easiest of all (assuming that there's WG agreement) is deprecating old
keys. Get rough consensus, and it's about a half-hour work from me.

    Jon

To: Rodney Thayer <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: meeting in San Francisco?
Date: 05 Mar 2003 20:27:08 -0500
Lines: 44
Sender: [email-masked]

Well, at this point is it too late to get a meeting slot in SF.  Sorry.

-derek

Rodney Thayer <[email-masked]> writes:

> At 03:28 PM 2/19/2003 -0500, Derek Atkins wrote:
>  >Rodney Thayer <[email-masked]> writes:
>  >
>  >> Is there a meeting planned in San Francisco?  Is there an agenda?
>  >> Is there a call for an agenda?  Is there interest in a meeting?
>  >
>  >I dont know.  No.  There should be.  Good question..
>  >
>  >Feedback?
> 
> A cypherpunks meeting is a separate topic, I was talking about an IETF
> WG meeting.  So I'm not ignoring that.
> 
> Things I think we should discuss:
> 
> - draft 07bis or 08 or whatever it's at (Jon?  does this make sense?)
> 
> - the key server protocol activity that the keyserver-folks and Peter Gutmann
> have been discussing.  I think I'm in the midst of volunteering to do a short
> presentation on that, so I would like to ask for a 15 minute slot
> 
> - ben laurie's perfect forward secrecy draft.  which he kept trying to bring
> up as a discussion topic.  I'm not claiming it's perfect or anything
> but I think
> we should at least discuss it.  I'm sure we can rope someone into doing
> a short presentation on this.
> 
> - deprecating pgp 2 keys.  I don't happen to like the idea myself, but lots of
> people (Len?) have strong opinions about this and therefore I think
> the WG should
> discuss it, at least a little bit, at least to form a "wg opinion".
> 
> 

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

Date: Wed, 05 Mar 2003 16:29:28 -0800
To: Derek Atkins <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: meeting in San Francisco?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 03:28 PM 2/19/2003 -0500, Derek Atkins wrote:
 >Rodney Thayer <[email-masked]> writes:
 >
 >> Is there a meeting planned in San Francisco?  Is there an agenda?
 >> Is there a call for an agenda?  Is there interest in a meeting?
 >
 >I dont know.  No.  There should be.  Good question..
 >
 >Feedback?

A cypherpunks meeting is a separate topic, I was talking about an IETF
WG meeting.  So I'm not ignoring that.

Things I think we should discuss:

- draft 07bis or 08 or whatever it's at (Jon?  does this make sense?)

- the key server protocol activity that the keyserver-folks and Peter Gutmann
have been discussing.  I think I'm in the midst of volunteering to do a short
presentation on that, so I would like to ask for a 15 minute slot

- ben laurie's perfect forward secrecy draft.  which he kept trying to bring
up as a discussion topic.  I'm not claiming it's perfect or anything but I 
think
we should at least discuss it.  I'm sure we can rope someone into doing
a short presentation on this.

- deprecating pgp 2 keys.  I don't happen to like the idea myself, but lots of
people (Len?) have strong opinions about this and therefore I think the WG 
should
discuss it, at least a little bit, at least to form a "wg opinion".