> Speaking personally, not as editor.
> First, I can live, both personally and as editor, with Dave's
> latest proposed text (although I'd prefer to see S/MIME added
> back in).
> But I think that, in the quest of apparent precision, we are
> being a little unrealistic. There are digital signature systems
> around and in use that do not conform to the IETF-standardized
> versions of DKIM, PGP, and S/MIME. There are still environments
> in which message content is secured by computing a message
> integrity check values and then sending that value over a
> separate channel, independent of the message itself. In the
> general case -- the three IETF-standard protocols excluded-- we
> can't even have a general expectation that the Submission server
> will be able to recognize the presence of a signature mechanism
> because that mechanism may be supported through
> undocumented/non-standard message header fields or
> undocumented/non-standard envelope fields. In the case of
> out-of-band transmission of a MIC, there may be no hint at all
> in the envelope or message that a check is being done.
This is the same primary point, more or less, that I made in my original reply.
It's why it's simply wrong to be using compliance language here, irrespective
of the process issues with adding it to a full standard: Since you cannot in
general tell if a signature/hash/mic/whatever is even being used, short of
never touching message content at all, including stuff like MIME downgrading,
you cannot possibly honor a "SHOULD respect any signature scheme that is
present".
> Depending on the method used, what it signs or verifies, and
> what canonicalization is specified, many of the transformations
> explicitly permitted by submission servers may mess things up,
> usually be rendering a signature or separate MIC invalid.
Yep, although I note that your chances are a lot greater if you restrict your
signature to inner message content and use the generic multipart/signed
container to indicate its presence.
> Keeping in mind that we assume, at least formally, that
> Submission servers are under the administrative control of the
> sender, we can sensibly advise that the sender make sure the
> Submission server is aware of any specialized constraints on its
> actions (not only ones associated with signatures, although
> those may be the most important case). We can sensibly advise
> (and probably should, given the concerns Russ identified about
> invalid signatures versus no signatures) that part of that
> Sender (or MUA) communication with the submission server include
> agreements about whether the Submission server should remove
> possibly-affected signatures, ignore the problem, re-sign the
> message with its own keys and mechanisms (or incrementally if
> that is feasible), or even return the message to the submitter
> with an explanation of the problem.
> Other than advising such communication (which is better than a
> dragon-warning, but maybe not much), there really isn't anything
> we can say here because such statements would be very
> method-dependent and possibly dependent on the submission
> environment (as well as too dependent on the details of
> less-mature protocols to be appropriate in a full standard).
> I think Dave's phrasing is better than the original, but I don't
> think we should delude ourselves that it supplies real advice.
> All it does is to make a statement about damage that can occur,
> leaving it to the imagination of the reader or implementer what
> should be done about it. In that sense, it is just a
> translation of the original "there be dragons" warning into
> slightly more attractive standards-language. Again, if that is
> what the community wants, I'm ok with it. But we are spending a
> lot of time on this for a very small incremental gain over
> either saying nothing or saying "Submission servers should be
> really, really, careful that their well-intentioned changes to
> messages don't screw things up".
I think it's important to at least point it out so that there's some
chance people will at least be aware of the issue. I agree that anything
more is too much.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
