Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt

From: [email-masked]
Date: Mon, 9 Jun 2008 11:00:02 -0700 (PDT)

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-05.txt
	Pages		: 22
	Date		: 2008-6-9
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 9 Jun 2008 22:02:35 -0400

3.1 

"   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>>"

This might impact ITIP and possibly iCal, but we may need a mechanism for an
Organizer to sign a security token when creating/authorizing a delegate, and
require that token to be present in anything sent on the Organizer's behalf.
This would be signed by the Organizer with the Organizer's private key, so
that it would be verifiable by decrypting it with the Organizer's public
key. I'm not a security expert, but it could be as simple as encrypting the
Organizer's RFC2822 address as the token and then upon decryption verifying
that it matched that of the Organizer.

After 3.5
 
"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 suggest that the answer to this question is "No", because if the
attacker has successfully interposed itself between the "other end" and this
CUA, any notification attempt would notify the attacker, allowing it to
withdraw and remove traces.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, June 09, 2008 2:00 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 

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-05.txt
	Pages		: 22
	Date		: 2008-6-9