"Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> writes:
In <iluy8uj7p99(_dot_)fsf(_at_)latte(_dot_)josefsson(_dot_)org> Simon
Josefsson <simon+ietf-822(_at_)josefsson(_dot_)org> writes:
The problem is that the above procedure is flawed, so it is not always
possible to use it in the real world. There are several problems with
that text, I believe the two major issues are:
1) It leads to invalid MIME messages on the wire. After following the
above procedure, what is sent is a message marked with CTE qp but
only the contents of the inline PGP message actually follow the QP
rules. The PGP armor itself do not follow the QP rules.
No, I don't think that is right. There are basically two ways of signing
PGP messages:
1. The "usual" way. You construct a text A, pass it through a PGP signing
engine to get text B (it will do nasty things like changing every initial
"---" on your lines to "- --"). Text B will contain the usual PGP
wrappers, your text, and the PGP sig.
You then email Text B, and if you can persuade you mailer to encode it as
7bit, then any trailing spaces (which were not included in the PGP hash,
but are still present in your text) will be protected against munging en
route. Note that it is your original text that is signed, not the QP
version.
I agree with you that it isn't right, but it is what the draft says.
That's my point. The text was quoted in my replace, but here is the
text again:
5.6. Digital Signatures and Encryption
If a message is digitally signed or encrypted it is important that
cryptographic processing use the on-the-wire Format=Flowed format.
That is, during generation the message SHOULD be prepared for
transmission, including addition of soft line breaks,
space-stuffing, and [Quoted-Printable] encoding (to protect soft
line breaks) before being digitally signed or encrypted; similarly,
on receipt the message SHOULD have the signature verified or be
decrypted before [Quoted-Printable] decoding and removal of stuffed
spaces, soft line breaks and quote marks, and reflowing.
The text say that MUAs SHOLD do things differently from what you
describe.
FWIW, your approach has the security problem that started this thread;
it makes it possible for someone to in transit add trailing SPC to the
PGP message, and add a format=flowed tag to the headers, without being
detected.
I haven't seen a way to support both inline PGP and format=flowed
without creating one problem or another.
Btw, it is not clear if the paragraph apply to PGP/MIME too. Because
it uses generic terminology, I assume it apply to all cryptographic
formats. RFC 3156 already discuss these issues, repeating them again
with normative text might just be confusing. And my claim is that,
for inline PGP, the normative text doesn't work.
I'd love to be proved wrong on this, since currently I'm stuck in my
implementation of inline PGP and format=flowed, because of my
perceived problems.
I thing Gellens is right in that the there are more modes than what
you describe. There are at least 4 incompatible ways to do inline
PGP; QP before, QP after sign (but don't touch PGP armor), QP after
sign (including PGP armor), don't QP at all. I have seen all of them
in the wild. Incidentally, my experiences is that the last one works
best, although it breaks the most specifications. The format=flowed
draft says only one of the SHOULD be used even though it violate MIME.
2. Use RFC 3156 (PGP/MIME).
Right. This is what I believe should be used instead.
Just for the hell of it, I shall sign this message both ways (so the outer
signature will actually sign the inner one).
It wasn't a good example, since you didn't use QP. For pure 7-bit
messages, there are no ambiguities at all, as far as I know. Well,
except that you might prefer to use QP to protect leading '-' from
hash escaping ('- -'), otherwise RFC 1991 implementation cannot
understand the message. This is also not written down anywhere, I
believe.
Regards,
Simon