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

From: Jon Callas <[email-masked]>
Date: Tue, 18 Jan 2000 14:18:52 -0800

At 8:40 PM +0100 12/23/99, Ulf Möller wrote:
>   PKCS-1 block type 02 [RFC2437] (Was: [RFC2313]) to form the "m"
>   value used in the formulas above.
>
>You need to observe the changes in terminology if you refer to the new
>PKCS #1.

Could you do me the favor of telling me what the changes in terminology
are? If I have to guess at what you'd like, I will probably disappoint you.

>
>The signature packet format is still specified as including "zero or
>more subpackets", but the subpacket hints section mentions in passing
>that two packets are mandatory.

Done.

>
>The notes about backward compatibility don't mention that PGP 2
>requires certain formats for some packet types.
>

The RFC isn't a how-to guide for writing PGP 2 compatible applications. We
don't even *require* it, although we encourage it, even to the point of
allowing an exception for the sake of interoperability. There are a number
of hints and guidelines scattered all through the document about what PGP 2
can and can't accept. I know it's not comprehensive, and never will be;
that is not a goal of OpenPGP and never has been. However, if there's
something glaring that we've overlooked, or something that tripped you up,
I'm more than willing to put it in.

One of the reasons I keep saying "tell me what you want" is that I'm really
close to the issue. I've poured over the document a zillion times, and I
know there are things that seem perfectly obvious to me that aren't to
other people. It's hard for me to know which ones those are. My opinion is
that if someone else finds a part of the RFC confusing, incomplete,
inobvious, or just plain brain-dead, then it is! I will fix it.

I've just spent a half-hour on this. I know that PGP 2 compatibility
requires old length types, V3 data structures (keys and sigs), and only
RSA, MD5, and IDEA. Is this what you want me to say in a hint? Is there
something more subtle that I'm forgetting, but once you mention it I'll
say, "Duh, of course"?

>I don't think the note
>     * (Added:) PGP 2.6.X and 5.0 do not trim trailing whitespace from a
>       "canonical text" signature. They only remove it from cleartext
>       signatures.
>is particularly clear on how to interoperate.
>

If you don't think it's particularly clear, then it isn't. I'll hazard a
guess here. OpenPGP requires that a canonical text signature trim trailing
whitespace. These old versions do not. Consequently, if you see a canonical
text signature, then you have a number of choices, among them are: (1) Flag
it as a mal-formed message, and thus an error. (2) Compute the signature
using the trailing white space. (3) Compute the signature with white space,
and if that fails, re-compute it without white space.

I can't tell you as an implementer which is the right one. As a user, I'd
prefer you did (3), as it follows the principle of being liberal in what
you accept. However, I don't blame you if you roll your eyes as a developer
and say that you don't want to do that. The RFC doesn't require you to be
nice, and you may have a lot of good reasons for not doing that. (As an
example, you may be working on a constrained platform, like a pager or a
handheld, and you don't want to bloat your code.)

I intended the the note to be a heads-up that you may see a signature that
is  not RFC 2440 compliant. How you handle it is your business; I'm not
going to tell you how to write your code (but I may say, "I would have
decided differently."). It's your decision.

I've changed the paragraph to:

PGP 2.6.X and 5.0 do not trim trailing whitespace from a "canonical text"
signature. They only remove it from cleartext signatures. These signatures
are not OpenPGP compliant -- OpenPGP requires trimming the white space. If
you wish to interoperate with PGP 2.6.X or PGP 5, you may wish to accept
these non-compliant signatures.

Feel free to make edits or additions.

>The security notes should mention that only v3 RSA signatures are bound to
>the hash algorithm, so that v4/DSA signatures can be forged if any one of
>the hash algorithms is broken, even if the signer doesn't use that algorithm.

I think I'm confused here. Suppose I have an implementation that does DSA
with SHA-1. Let us also suppose that Tiger gets broken. How does this
affect my DSA/SHA signature?

	Jon

---

From: Ulf Möller <[email-masked]>
Date: Wed, 19 Jan 2000 19:56:35 +0100

> are? If I have to guess at what you'd like, I will probably disappoint you.

PKCS #1 v2.0 speaks of "encoding methods" rather than "padding", and
"block type 02" is now called EME-PKCS1-v1_5.  EMSA-PKCS1-v1_5 means
making the DigestInfo and encoding it according to what was previously
called "block type 01".

> something more subtle that I'm forgetting, but once you mention it I'll

For example key and signature packets must use length type 1, it
doesn't accept length type 0.  I descibed that on this list quite some
time ago.

> affect my DSA/SHA signature?

Then if I want to forge a signature, I find a message for which the
Tiger hash value is identical to your original SHA-1 hash.  Unless
your original signature was a v3 RSA signature, nothing in OpenPGP
prevents me from setting the hash algorithm identifier for that
message to Tiger.  That's why the RSA value in PKCS #1 contains a
DigestInfo, and why the DSS specifies SHA-1 as the only signature
algorithm.  Putting the hash algorithm identifier in the data
protected by that very hash algorithm is pointless.

That clearly is a cryptographic weakness in the protocol, so it has to
be mentioned in the RFC. (By the way, OpenPGP allows MD2 as a hash
algorithm without a warning about its security, so this attack may
well be practical. But even if the verifying implementation only
accepts algorithms that are not known to be insecure, allowing the
attacker to chose a hash algorithm makes the protocol weaker not
stronger.)