At 04:08 PM 2/11/99 -0800, Russ Allbery wrote:
|Pardon me if I'm confused here, but wouldn't that involve checking any
|failing detached text-mode signature a second time with the original data
|without trailing whitespace stripped to see if it then passes?
|
|And isn't it impossible to both follow the RFC and generate detached
|text-mode signatures that will verify correctly with PGP 5.0 if the data
|has trailing whitespace? In that either the signatures will verify with
|PGP 5.0 or they will verify with RFC-compliant checkers, but never with
|both?
Here's my interpretation of what you should do:
Remember that we're not talking about clear-signed messages, we are talking
about a message that is a literal packet and a signature packet (and
possibly this pair has been encrypted).
If you are constructing the message, construct it in canonicalized text.
Line ends are CRLFs, and lines are blank-trimmed. Construct the signature,
send the message. All things being equal (that is, excepting the cases
where you have a DSS sig sent to 2.6 etc.), it will always work. The
literal packet should be a text-mode literal packet.
When you receive a message, don't go interpreting it. Do nothing. Compute
the signature. In the case where you have a non-blank-trimmed literal
packet, don't even look for the flaw here. The signature will work
correctly for anyone who constructed it correctly, and it will work for
anyone who was merely stupid. That's what I meant by rolling your eyes and
proceeding. My suggestion is that by doing zero work, you handle all
correctly contrusted messages, and many incorrectly constructed messages.
There are a number of flawed cases, here, too. I'm using the word "flaw"
only to avoid a more perjoritive term like "erroneous" because I don't want
to get into those arguments.
One flawed case is a text mode literal that has not been blank trimmed, but
is otherwise correctly textmode. It's followed by a textmode sig packet.
The "do no work" precept lets this one work.
Another is a textmode literal that contains carriage control -- for example
one that underscores by using a bare CR. The "do no work" precept lets this
one work, and a smart implementation is likely to damage this packet.
Another is a mal-formed textmode literal. For example, it just put unix
text (LF endings) into a textmode packet. The DNW precept makes for a
correctly formed signature, but there may be errors when the file is
written out (or maybe not, if the texmode literal processor has
error-adaptions in it). But that's a different problem.
More problematic is a textmode literal with trailing blanks, with a sig
calculated by trimming them. Here, DNW fails. This is also where the real
crux of the problem is. I believe that it's possible to have "minimal"
implementations and "friendly" implementations. A minimal implementation
will fail to verify the signature. This is in my opinion fine, because I
believe that a compliant 2440 application will be *generating*
blank-trimmed signed text. If the trailing blanks were that important to
you, there's always binary mode, y'know? A friendly implementation,
however, is free to see that the signature failed and try again using a
different strategy (such as blank trimming or blank trimming with line-end
conversion) and see if the signature works with this.
It's my opinion that if a 2440 application wants to send a textmode message
with trailing blanks then the obvious, right way to do it is to put a
binarymode signature after the textmode literal. That's what binarymode
means -- don't mess with the content, just hash it straight. To me,
textmode signatures are an *assurance* that the literal packet it signs met
those criteria when it was generated. If it doesn't, you could have
constructed a textmode message and signed it in binary mode. To tie in what
I said before, this means that a 2440 app conservatively generates a
message by trimming a textmode packet if it is going to textmode sign it,
so there will be *no* *question* how to interpret it.
Now then, having said that, reality is that we live in a world with a mass
of implementations of PGP, all of which are more-or-less 2440ish. A
friendly application can consider the textmode signature packet when it
*receives* it to be an alert that it may have to futz with the hashing to
be fully forwards compatible. Note that a 2440 application is not required
to do that. That's the difference between minimal and friendly. No one says
you have to be friendly.
(Here's another comment of mine that only relates to comments that I've
made here and before that you're permitted to go beyond the spec. 2440 says
that textmode literals have CRLF line ends. It's my considered opinion that
textmode should also trim blanks. You're free to disagree, but if I were
writing a 2440 app, I'd trim blanks. I probably would also allow textmode
conversions to do tab/blank conversions and possibly paragraph
reformatting. 2440 is silent on all of these. That does not mean that one
is forbidden from doing them. If you're the implementer, you get to make
these decisions yourself.)
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 3965 Freedom Circle
Network Associates, Inc. Santa Clara, CA 95054
(408) 346-5860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)