From: Chris Newman (Chris.Newman@innosoft.com)
Date: Mon Jul 27 1998 - 17:36:42 CDT
On Fri, 24 Jul 1998, Charles Lindsey wrote:
> 1. It must be equally applicable to mail and news.
Yup.
> 2. That probably means it will have to be done in a separate RFC, by a
> group established for that specific purpose. But let us continue to
> discuss it here in the meanwhile.
Likely.
> 3. Mail and news both tend to munge things (yes, I know they are not
> _supposed_ to), but they tend to do it in different ways, and mail tends
> to do it more than news. Examples:
> a) The order of headers can change (esp in mail).
> b) Headers may get folded or unfolded or refolded (with addition
> or loss of comments).
Your parenthetical comment is the kicker. It turns out that some comments
are required by standards (e.g., RFC 1327). So if you ignore them on
signature, you open up a security hole, but if you don't ignore them, then
they'll probably be tampered with by a system they pass through which is
working around parser bugs in other systems.
> 4. The basic requirement is the ability to sign _critical_ headers.
> Signers should be encouraged to sign as little as possible, consistent
> with achieving the security they are after. What is critical for one
> application is not necessarily critical for another.
I disagree. When designing security systems, it's dangerous to open up
"subliminal channels" where data can be passed without being noticed or
protected. It's particularly dangerous to impart a false sense of
security. If the "headers" are signed, but in reality only some of them
are, that's bad because an administrator has to be familiar with the
standards to know which are signed if he's tracing abuse. I'd conclude
that you either need to sign *all* headers or none of the headers. At
this point, the problem again becomes intractible since you can't know
what headers will get modified or added in transit.
> 5. The ability to sign the bodies at the same time is useful, but
> increases the difficulties (in particular, bodies are subject to a
> different set of mungings than headers - notably the changes of
> Content-Transfer-Encoding and the treatment of trailing empty lines).
I wouldn't worry about this too much.
> 6. We must accept that different agents that a message or article passes
> through will feel the need to sign different things (for example, the
> poster may sign some fields, and then the moderator may like to sign the
> Approved header). So multiple signatures must be possible.
This makes the system very complex. I think the requirement is not to be
able to sign different content, but rather to have multiple signatures of
the content which grant different permissions. If this is part of an
attribute-based signature system, then the result is *much* simpler.
> 7. There should be means to incorporate verifications of signatures
> (perhaps themselves signed) both because individual readers may not have
> access to all the public keys involved, and because gateways may
> sometimes be forced to break the original signature. Signature collapse
> also fits in here somewhere.
This has to be done very carefully, if at all. Once you have different
levels of signature "quality" the UI becomes intractible. I also think
this requirement should be moved to the leaf nodes -- avoid complexity in
the core. I'd do this with an extension for client access to an NNTP or
IMAP server where the client can ask the server to verify the signature.
I think it's best to avoid doing this stuff in the core transport.
> An umbrella RFC, setting out multipart/signed containing a body-part and
> a signature-part. The body-part contains its own
> Content-Transfer-Encoding (can be omitted if it is 7bit). This MUST NOT
> be 8bit or binary "if EVER" the material is to be transferred over SMTP
> (so 8bit _could_ be legitimate in news).
There are ways to work around this latter requirement. The micalg
parameter can be slightly overloaded to provide a canonical-form based
MIC.
> The text that you sign is the text AFTER it has been Transfer-Encoded. I
> believe this to be a terrible decision, but there it is. One problem is
> what to do about MIME-headers in the body-part (suppose there is a
> Subject header) that contain non-ASCII characters? They do not get
> Transfer-Encoded. RFC 2047 perhaps. Of course, this is not supposed to
> happen in mail (come to think of it, how is it handled in our draft?)
> and the MIME RFCs have never looked beyond mail.
The MIME RFCs did look beyond email. However, they were designed for
lowest common denominator maximum interoperability. And remember that
UTF-8 didn't exist when MIME was designed.
> 2. RFC1848: MIME Object Security Services (MOSS)
>
> This is a derivative of RFC1847 which repeats all of RFC1847 at great
> length and in mind-numbingly boring detail. It is best forgotten about.
This was PEM + multipart/security. PEM was an overcomplex abortion and so
is MOSS. I agree it's best forgotten about.
- Chris