ietf-smime
[Top] [All Lists]

Re: sender-auth and ira

2001-10-25 09:36:16

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

<Prev in Thread] Current Thread [Next in Thread>