Re: IESG Review: draft-ietf-fax-esmtp-conneg-10.txt

Graham,

>>   Content conversion will invalidate a message's signature and will not
>>   be possible to perform with encrypted content. Therefore, permission
>>   to convert SHOULD NOT normally be given with signed or encrypted
>>   messages.

GK> on reflection I find that I'm uncomfortable with the implication that
GK> content negotiation and security are mutually exclusive options.

For existing techniques, it is, absent the intermediary's access to
the sender's private key information.


GK> In the case of signature, I can imagine the possibility of a trusted

I can imagine that, too, but it is not reflected in current
techniques.

So perhaps a softening of the language, but not much.

(pretending that I haven't read the rest of your note:) Let's remember
that none of this discussion in the document means all that much,
really. It's not as if we are really telling readers things they are
that likely to be ignorant of.

That is, I think there is a legitimate obligation that the
specification highlight important implications.  But I do not think
that highlighting these implications requires legalistic or
mathematical precision.  Signposts, not lasers.


GK> I think these are significant issues to explore with respect to content
GK> negotiation and security, but also think there's a reasonable concern about
GK> how much detail is required.

right.


GK>  I'm thinking that the text should cover the
GK> following points (and avoid the SHOULD NOT used above):

GK> 1. If a document-converting intermediary fails to ensure that the resulting
GK> converted content is similarly protected, then the benefits of the
GK> originally applied security are lost.

good core point.

However...

Rather than going into the detail you provide with your list, I
suggest a single, simple statement:

        If a message is protected by strong content authentication or
        privacy techniques, then an intermediary that converts message
        content MUST ensure that the results of its processing are
        similarly protected.  Otherwise it MUST NOT perform
        conversion.


d/
--
 Dave Crocker <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>