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