____________________________________________________________________ Before a larger group can see the virtue of an idea, a smaller group must first understand it. "Stranger Suns" George Zebrowski The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- -------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Tue, 13 Feb 2001 13:54:27 +0100 From: Thomas Roessler <roessler@does-not-exist.org> Reply-To: ietf-openpgp@imc.org To: mail-client-dev-list@lists.sourceforge.net, pgp-mime@lists.uchicago.edu, coderpunks@toad.com Cc: ietf-openpgp@imc.org Subject: PGP/MIME implementors: text mode vs. binary mode? Please forward this message to any implementors of PGP/MIME you are aware of. To whom it may concern. In the ietf-openpgp working group, we are about to finish a revised version of RFC 2015. While this looked like an easy task at first sight, it is not, since OpenPGP breaks traditional pgp's text-mode signatures. This message is to solicit further input and comments from other implementors of PGP/MIME. (We thought we were done, but then there were more arguments against the solution we believed to have found...) The current draft is draft-ietf-openpgp-mime-04.txt, and available from: <http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-04.txt>. Please direct any answers to this message to the ietf-openpgp mailing list. In order to subscribe to that list, send a message to <ietf-openpgp-request@imc.org> with the single word "subscribe" in the subject. The Problem. To pgp 2 and 5, a text-mode signature meant that line endings were transformed to a CR-LF sequence, and the result was then hashed. However, with OpenPGP, preparing a text-mode signature has another effect: Trailing blanks (and tabs?) are stripped - this is what used to be done as a clear-sign signature with traditional PGP. Of course, this is a bug in the spec, but one which won't be easily fixed now that all the implementations are out there. Now, for PGP/MIME, this turns into a really ugly problem: RFC 2015 does not specify which kind of signature to use. However, it does specify how the signed material should be canonicalized before hashing. This method of canonicalization exactly matched what was done by traditional PGP versions for text mode signatures, which means that the very same hash value could be used to verify either a text-mode or a binary-mode signature. That way, PGP/MIME according to RFC 2015 and with traditional PGP had the desired one-pass properties. With OpenPGP, this construction breaks badly as soon as trailing white space is involved. Since it doesn't look right or elegant to ask implementors of one-pass parsers (if they exist) to calculate two hashes in parallel, some decision has to be made on the kind of signature which should be mandated for the future. I'm listing the choices and the pros and cons I'm seeing: * text-mode signatures + easy to implement if you invoke a command-line tool to which you can leave the details of canonicalization. - Ian Bell of turnpike.com tells me that it's hard to persuade the PGP SDK to produce detached text-mode signatures. + the new-style text-mode signatures will nicely ignore any whitespace changes which are irrelevant to the message's content (When used the right way, MIME is invariant under modifications of trailing whitespace.) - there are incompatibilities between implementations which use text-mode AND leave trailing white space in messages. - thus, clients will need additional code in order to avoid trailing whitespace (e.g., apply quoted-printable). - this will make any clients non-compliant which are using binary mode today. * binary-mode signatures + easy to implement if you use the PGP SDK (I'm told). + clients are interoperable regardless of the back-end version used and regardless of the treatment of trailing whitespace. - those people who rely on "pgp -t" will have to add some code to pass canonicalized data to the back-end. In some cases, this may badly break things. - signatures will break upon changes to trailing white space which don't affect the message's content or MIME semantics - thus, clients may need additional code in order to avoid trailing whitespace (e.g., apply quoted-printable). - this will make any clients non-compliant which are using text mode today. Bottom line: The decision what to mandate boils down to the question what implementors prefer. And, yes, both alternatives are bad solutions. Thus, if you are an implementor of PGP/MIME, please subscribe to the ietf-openpgp mailing list, and let us know what should be done in your opinion, and why. Also, please tell us what mode you are using nowadays, so we get a more precise impression of what software we are going to break. Thanks, and kind regards, -- Thomas Roessler <roessler@does-not-exist.org>