At 10:04 AM -0400 10/25/01, Housley, Russ wrote:
Two I-Ds were posted, and I have not seen a single comment on them.
I hope this message starts a dialogue.
Success. :-)
The two I-Ds are:
draft-ietf-smime-sender-auth-00.txt
draft-ietf-smime-ira-00.txt
The first one describes a problem, and the second one defines a
solution for this problem. I would expect the first one to be
published an Informational RFC and the second to be published as a
Standards Track RFC.
The first draft (sender-auth) defines the problem with a lot of
hyperbole. The second draft (ira) defines the problem much better. I
would object to the first draft being moved even to Informational
status unless:
- it was significantly shortened
- more emphasis was put on how to avoid the problem without protocol
changes ("If Alice puts Bob's name in the first line of the
message..." and "If the purchase order has the intended recipient's
name in it")
- it is stated that the damage that is done by the recipient's
carelessness is mostly theoretical and cannot happen when there is
intended addressing information in the content
The solution in the ira draft is much better than the solution in the
sender-auth draft in that it applies to things other than RFC 2822
messages. It seems likely that the sender-auth proposal will become
non-interoperable when there are many RFC 2822 headers with
recipients in them (such as two To: headers) and with things like
header folding. I think the ira draft stands on its own with the
problem description and solution.
Both drafts would be a lot clearer if they said "sign then encrypt"
instead of "sign and encrypt". The word "and" does not mean "then" in
most languages, and doesn't necessarily mean it in English.
--Paul Hoffman, Director
--Internet Mail Consortium