[ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-06.txt

[Alexey Melnikov]

Internet-Drafts at ietf.org wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.
>
>	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
>	Author(s)	: A. Melnikov
>	Filename	: draft-ietf-calsify-rfc2447bis-06.txt
>	Pages		: 22
>	Date		: 2009-9-9
>  
>
There were only minor changes in this version, namely changing the 
reference to RFC 2822 to point to RFC 5322, and updated boilerplate.

In order to get this document finished, I need to get feedback on the 
following:

>3 Security Considerations
>
>   The security threats that applications must address when implementing
>   iTIP are detailed in [iTIP]. In particular two spoofing threats are
>   identified in [iTIP]: Spoofing the "Organizer", and Spoofing an
>   "Attendee". To address these threats, the originator of an iCalendar
>   object must be authenticated by a recipient. Once authenticated, a
>   determination can be made as to whether or not the originator is
>   authorized to perform the requested operation. Compliant applications
>   MUST support signing and encrypting text/calendar body parts using a
>   mechanism based on Security Multiparts for MIME [RFC-1847] to
>   facilitate the authentication of the originator of the iCalendar
>   object. The steps for processing a signed iMIP message are described
>   below:
>
>   1. The iCalendar object MUST be signed by the "Organizer" sending an
>   update/initial request or the "Attendee" sending a reply.  <<Or the
>   person sending on their behalf? Clearly if somebody else is sending
>   the invitation, she can't sign using the key belonging to the
>   organizer>>
>
What do we want to say about the delegated case?

>   Once a signed and/or encrypted iMIP message is received and
>   successfully verified (as detailed above) by a CUA, the CUA SHOULD
>   remember whether the sender of the message is using signing and/or
>   encrypting.  If an unsigned iMIP message is received from the same
>   sender later on, the receiving CUA SHOULD warn the user about a
>   possible man-in-the-middle attack and SHOULD ignore the message,
>   unless explicitly overriden by the user. <<Should it also try to
>   notify the other end?>>
>
I would like to get feedback on whether notifying the other end is a 
good idea in this case.

Thanks,
Alexey