Re: sender-auth and ira

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

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