Skip to main content

Last Call Review of draft-ietf-calsify-rfc2447bis-

Request Review of draft-ietf-calsify-rfc2447bis
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-09-07
Requested 2010-08-06
Authors Alexey Melnikov
I-D last updated 2010-09-05
Completed reviews Secdir Last Call review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Request Last Call review on draft-ietf-calsify-rfc2447bis by Security Area Directorate Assigned
Completed 2010-09-05
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

The document describes the "iCalendar Message-Based Interoperability
Protocol (iMIP)", a protocol for transmitting calendar events over

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 <sent-by, organizer> 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.