The draft really needs an initial paragraph stating the purpose. It
is a guide to security for desigers of services for SMTP using OPES
processors? A prototype "security considerations" section for any
OPES/SMTP protocol documents? Or is it only for the purpose of
"revisiting" the IAB considerations? I'm confused about this, because
the draft mentions RFC3914 (OPES vs. IAB consideration) in its
introduction but only mentions RFC3837 (Security ... for OPES) at the
end as something with "generic" considerations. So I think the draft
positions itself as a refinement of RFC3914, despite its generic
title. The first paragraph should explain this.
Section 3.3 was motivated by text in the introduction to RFC3238. I
have always believed that the IAB was seriously in error when it wrote
that paragraph, because it confuses encryption with integrity and
misuses the term end-to-end. The result is an impossibility. To cope
with this, the draft MUST substitute the words "cryptographic message
integrity" for "encryption" in all cases and note that if the
protection is based on symmetric keys, then the problem of key sharing
is a grave security risk, but if the protection is based on asymmetric
keys, then the desired protection is possible. Section 5.8 should
note that section 3.3 is an interpretation of the the most likely
intent of the authors of RFC3238.
I think I've expressed confusion about this text before:
the receiver should be able to
indicate if he/she wants to receive a non-OPES version if the OPES
service would result in rejection of the email.
If this means that the OPES processor itself reaches a "reject" decision,
that's fine. But if it means that it modifies the message in such a way
that it violates some other local policy and is rejected after it leaves
the OPES processor, then the text isn't fine. Please clarify.
Hilarie