Subject: Re: Further deprecating PGP2

From: [email-masked] (Peter Gutmann)
Date: Sat, 8 Mar 2003 20:56:22 +1300

"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.

---

From: Jeroen van Gelderen <[email-masked]>
Date: Sat, 8 Mar 2003 16:06:18 -0500

> 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

---

From: Derek Atkins <[email-masked]>
Date: 10 Mar 2003 12:30:56 -0500

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

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

---

From: Jeroen van Gelderen <[email-masked]>
Date: Mon, 10 Mar 2003 14:18:04 -0500

Derek,

> 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.

> 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

Cheers,
-J

---

From: David Shaw <[email-masked]>
Date: Mon, 10 Mar 2003 15:16:15 -0500

> 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

---

From: Jeroen van Gelderen <[email-masked]>
Date: Mon, 10 Mar 2003 16:03:17 -0500

> anyone sending you an OpenPGP message that uses IDEA is already

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.)

> subject to the OpenPGP spec.

Definitely.

> draft has already done this).

Yes, that is lovely.

>   I also support deprecating the PGP 2.x

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

Cheers,
-J

---

From: David Shaw <[email-masked]>
Date: Mon, 10 Mar 2003 16:26:54 -0500

> 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.

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

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 10 Mar 2003 14:35:27 -0800

> the "OpenPGP side" of the program have IDEA?  No, but...

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

    Jon

---

From: David Shaw <[email-masked]>
Date: Mon, 10 Mar 2003 17:45:35 -0500

> 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

---

From: Derek Atkins <[email-masked]>
Date: 10 Mar 2003 18:34:14 -0500

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

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?

-derek

---

From: Adam Back <[email-masked]>
Date: Tue, 11 Mar 2003 00:06:01 +0000

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

---

From: David Shaw <[email-masked]>
Date: Mon, 10 Mar 2003 19:00:38 -0500

> 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

---

From: Adam Back <[email-masked]>
Date: Tue, 11 Mar 2003 01:19:56 +0000

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

---

From: Jon Callas <[email-masked]>
Date: Mon, 10 Mar 2003 17:43:44 -0800

> IDEA, and MD5 are not available algorithms, that's a clue to me that I

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

---

From: Derek Atkins <[email-masked]>
Date: 11 Mar 2003 12:24:49 -0500

> be achieved by you using an OpenPGP program that MAY support IDEA

Sure, that would be fine...

> "An OpenPGP MAY support decryption of IDEA-encrypted messages but MUST

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?

> 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.

> 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

---

From: Mike Markowitz <[email-masked]>
Date: Tue, 11 Mar 2003 11:28:26 -0600

>all V3 keys, we wouldn't stop decrypting messages with V3 keys. That's

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

---

From: Jeroen van Gelderen <[email-masked]>
Date: Tue, 11 Mar 2003 13:09:55 -0500

> reason why IDEA "MUST NOT" be used?

You are right of course.

> support older algorithms.

Yes.

> I'll give you extra points if the timestamp on the message is not 

How are the messages stored?

-J

---

From: Derek Atkins <[email-masked]>
Date: 11 Mar 2003 13:55:22 -0500

> How are the messages stored?

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

-derek

---

From: Jon Callas <[email-masked]>
Date: Wed, 12 Mar 2003 04:25:39 -0800

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.]

> 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

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

---

From: Ian Grigg <[email-masked]>
Date: Wed, 12 Mar 2003 16:37:56 -0500

> 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