Security review of draft-ietf-calsify-rfc2447bis-10 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments. The document describes the "iCalendar Message-Based Interoperability Protocol (iMIP)", a protocol for transmitting calendar events over SMTP. The security considerations are tied to authenticating the entity with the role of "Organizer" or "Attendee". The authentication relies on MIME security for attaching signatures and public key certificates. The SMTP sender is not relevant to the authentication. I'm slightly puzzled by the first step listed in "Security Considerations" about the steps needed to perform authentication. 1. Using the security mechanism compliant with [RFC-1847], determine who signed the email message containing the iCalendar object. This is the "signer". Note that the signer is not necessarily the person sending an e-mail message since an e-mail message can be forwarded. The confusion stems from the phrases "who signed the email message" and "the person sending". Would "who signed the MIME calendar part" and "the SMTP message sender" be more accurate? I think that MIME allows each part to have a different signer, and I think the protocol anticipates having MIME parts separated from the original SMTP message and forwarded in a different SMTP message. If that's the case, the rephrasing would make sense to me. There is an obvious slippery slope in the iCal "sent-by" parameter. It conflicts with the "organizer". The receiver is left with a dilemna: to authenticate wrt to the "sent-by" entity, or to insist on a signature by the "organizer". It seems to me that the "organizer" could have signed the event (including the "sent-by" parameter) in advance and given the MIME parts to the sender, so there is no need to trust the "sent-by" entity. Or, the receiver could have a list of trusted proxies in its local security policy. But, in general, I think that an event signed by an unknown or untrusted party should be given no special considertion --- it is the same as receiving an unsigned event, and "sent-by" is as irrelevant as the SMTP sender. Hilarie