> I think I've figured out how to reproduce this: export the key
> without ascii armoring. I believe that's illegal according to rfc
> 3156, but the error handling is no good.
Here I feel compeled to point out a couple of things:
1. Jon Postel's "Robustness Principle": be conservative in what you
do, be liberal in what you accept from others.
2. RFC 3156 is listed as a *PROPOSED* standard as of May 2008,
according to:
http://rfc.net/std1.html#s3.1.
It is not (yet) an official standard.
3. This RFC (#3156) states:
A MIME body part of the content type "application/pgp-keys"
contains ASCII-armored transferable Public Key Packets as
defined in [1], section 10.1.
[...]
References
[1] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
However, RFC 2440 makes no mention that the Public Key Packets
must, or even should be ASCII-armored.
4. RFC 2440 is also not an official standard. In fact, STD1 doesn't
even list it as a proposed standard, nor does the RFC list that it
is obsoleted by a superceding RFC.
RFCs are guidelines, not laws. Even if the proposed standards were
official, all software should obey the robustness principle, wherever
it is reasonable to do so. Is it reasonable to assume that some MUAs
were written to comply with RFC 2440, and attach non-ASCII-armored key
data, given that the RFC does not madate it be so? Seems reasonable
to me... Mutt should accept key data in this form.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
