Subject: What's the consensus?

From: Jon Callas <[email-masked]>
Date: Mon, 24 Mar 2003 14:28:46 -0800

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

---

From: David Shaw <[email-masked]>
Date: Mon, 24 Mar 2003 18:33:48 -0500

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

> someone feels strongly that we should say MUST, just say so. Also, provide

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

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.

> 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]>
Date: Mon, 24 Mar 2003 18:35:34 -0500

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

I generally agree.

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

> 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

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

> to go away. Given that RFCs, even if obsoleted, do not disappear, deleting

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