draft-ietf-calsify-rfc2447bis-08.txt   draft-ietf-calsify-rfc2447bis-09.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-08.txt Editor Document: draft-ietf-calsify-rfc2447bis-09.txt Editor
Intended status: Standard Track January 30, 2010 Intended status: Standard Track June 21, 2010
Expires: June 2010 Expires: December 2010
iCalendar Message-Based Interoperability Protocol iCalendar Message-Based Interoperability Protocol
(iMIP) (iMIP)
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
skipping to change at page 2, line 26 skipping to change at page 3, line 5
Abstract Abstract
This document, iCalendar Message-Based Interoperability Protocol This document, iCalendar Message-Based Interoperability Protocol
(iMIP), specifies a binding from the iCalendar Transport-independent (iMIP), specifies a binding from the iCalendar Transport-independent
Interoperability Protocol (iTIP) to Internet email-based transports. Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCalendar) Calendaring entries defined by the iCalendar Object Model (iCalendar)
are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC
2047 and RFC 2049, and then transported over SMTP. 2047 and RFC 2049, and then transported over SMTP.
This document is a product of the 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>
Table of Contents Table of Contents
1 INTRODUCTION........................................................2 1 INTRODUCTION........................................................2
1.1 RELATED MEMOS ...................................................2 1.1 RELATED MEMOS ...................................................2
1.2 FORMATTING CONVENTIONS ..........................................3 1.2 FORMATTING CONVENTIONS ..........................................3
1.3 TERMINOLOGY .....................................................4 1.3 TERMINOLOGY .....................................................4
2 MIME MESSAGE FORMAT BINDING.........................................4 2 MIME MESSAGE FORMAT BINDING.........................................4
2.1 MIME MEDIA TYPE .................................................4 2.1 MIME MEDIA TYPE .................................................4
2.2 SECURITY ........................................................4 2.2 SECURITY ........................................................4
2.2.1 Authorization ...............................................4 2.2.1 Authorization ...............................................4
skipping to change at page 5, line 23 skipping to change at page 5, line 23
This section defines the message binding to the MIME electronic mail This section defines the message binding to the MIME electronic mail
transport. transport.
The sections below refer to the "originator" and the "recipient" of The sections below refer to the "originator" and the "recipient" of
an iMIP message. In the case of a "request" method, the originator is an iMIP message. In the case of a "request" method, the originator is
the "Organizer" and the recipient is an "Attendee" of the event. In the "Organizer" and the recipient is an "Attendee" of the event. In
the case of a "response" method, the originator is an "Attendee" and the case of a "response" method, the originator is an "Attendee" and
the recipient is the "Organizer" of the event. the recipient is the "Organizer" of the event.
The [RFC-5322] "Reply-To" header field typically contains the email The [RFC-5322] "Reply-To" header field typically contains the email
address of the originator of the scheduling message. <<However, this address of the originator of the scheduling message. However, this
cannot be guaranteed as Mail User Agents (MUA) are not required to cannot be guaranteed because the sender of the iMIP message might not
enforce iMIP semantics.>> be the originator of the scheduling message and the sender's Mail
User Agent (MUA) might not enforce iMIP semantics by translating the
originator's address into the "Reply-To" email header field.
2.1 MIME Media Type 2.1 MIME Media Type
A MIME entity containing content information formatted according to A MIME entity containing content information formatted according to
this document will be referenced as a "text/calendar" content type. this document will be referenced as a "text/calendar" content type.
It is assumed that this content type will be transported through a It is assumed that this content type will be transported through a
MIME electronic mail transport. MIME electronic mail transport.
2.2 Security 2.2 Security
skipping to change at page 6, line 34 skipping to change at page 6, line 36
2.2.3 Confidentiality 2.2.3 Confidentiality
To ensure confidentiality using iMIP implementations should utilize To ensure confidentiality using iMIP implementations should utilize
encryption compliant with [RFC-1847]. The protocol does not restrict encryption compliant with [RFC-1847]. The protocol does not restrict
a "Calendar User Agent" (CUA) from forwarding iCalendar objects to a "Calendar User Agent" (CUA) from forwarding iCalendar objects to
other users or agents. other users or agents.
2.3 Email Addresses 2.3 Email Addresses
The calendar address specified within the "ORGANIZER" and "ATTENDEE" The calendar address specified within the "ORGANIZER" and "ATTENDEE"
properties in an iCalendar object MUST be a proper "mailto:" [MAILTO] properties in an iCalendar object send using iMIP MUST be a proper
URI specification for the corresponding "Organizer" or "Attendee" of "mailto:" [MAILTO] URI specification for the corresponding
the "VEVENT" or "VTODO". "Organizer" or "Attendee" of the "VEVENT" or "VTODO".
Because [iTIP] does not preclude "Attendees" from forwarding Because [iTIP] does not preclude "Attendees" from forwarding
"VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may "VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may
not equal that of the "Organizer". Additionally, the "Organizer" or not equal that of the "Organizer". Additionally, the "Organizer" or
"Attendee" cannot be reliably inferred by the [RFC-5322] "Sender" or "Attendee" cannot be reliably inferred by the [RFC-5322] "Sender" or
"Reply-to" values of an iMIP message. The relevant address MUST be "Reply-to" values of an iMIP message. The relevant address MUST be
ascertained by opening the "text/calendar" MIME body part and ascertained by opening the "text/calendar" MIME body part and
examining the "ATTENDEE" and "ORGANIZER" properties. examining the "ATTENDEE" and "ORGANIZER" properties.
2.4 Content-Type Header Field 2.4 Content-Type Header Field
skipping to change at page 8, line 41 skipping to change at page 8, line 45
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z DTSTART:20080701T160000Z
DTEND:20080701T163000Z DTEND:20080701T163000Z
SUMMARY:Phone call to discuss your last visit SUMMARY:Phone call to discuss your last visit
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0= DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
=B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0=BE=D0= =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0
=B9? =BE=D0=B9?
UID:calsvr.example.com-8739701987387998 UID:calsvr.example.com-8739701987387998
SEQUENCE:0 SEQUENCE:0
STATUS:TENTATIVE STATUS:TENTATIVE
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
2.6 Content-Disposition Header Field 2.6 Content-Disposition Header Field
Implementations MAY include a "Content-Disposition" header field to Implementations MAY include a "Content-Disposition" header field to
define a file name for an iCalendar object. However, the handling of define a file name for an iCalendar object. However, the handling of
skipping to change at page 10, line 20 skipping to change at page 10, line 20
"Attendee". To address these threats, the originator of an iCalendar "Attendee". To address these threats, the originator of an iCalendar
object must be authenticated by a recipient. Once authenticated, a object must be authenticated by a recipient. Once authenticated, a
determination can be made as to whether or not the originator is determination can be made as to whether or not the originator is
authorized to perform the requested operation. Compliant applications authorized to perform the requested operation. Compliant applications
MUST support signing and encrypting text/calendar body parts using a MUST support signing and encrypting text/calendar body parts using a
mechanism based on Security Multiparts for MIME [RFC-1847] to mechanism based on Security Multiparts for MIME [RFC-1847] to
facilitate the authentication of the originator of the iCalendar facilitate the authentication of the originator of the iCalendar
object. The steps for processing a signed iMIP message are described object. The steps for processing a signed iMIP message are described
below: below:
1. The iCalendar object MUST be signed by the "Organizer" sending an 1. Using the security mechanism compliant with [RFC-1847], determine
update/initial request; the "Attendee" sending a reply; or another who signed the email message containing the iCalendar object. This is
("uninvited") CU, who was forwarded a REQUEST, sending a reply. <<Or the "signer". Note that the signer is not necessarily the person
the person sending on their behalf? Clearly if somebody else is sending an e-mail message since an e-mail message can be forwarded.
sending the invitation, she can't sign using the key belonging to the
organizer>>
2. Using the security mechanism compliant with [RFC-1847], determine
who signed 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.
3. Correlate the signer to either an "ATTENDEE" property or to the 2. Correlate the signer to either an "ATTENDEE" property or to the
"ORGANIZER" property in the iCalendar object, based on the method and "ORGANIZER" property in the iCalendar object, based on the method and
the calendar component specified in the iCalendar object, as defined the calendar component specified in the iCalendar object, as defined
in Section 1.4 of [iTIP]. If the signer cannot be correlated to an in Section 1.4 of [iTIP]. If the signer cannot be correlated to an
"ATTENDEE"/"ORGANIZER" property (or is not authorized to act on her "ATTENDEE"/"ORGANIZER" property, then actively warn the user
behalf), ignore the message. controlling the calendar user agent that the iCalendar object is
untrusted and encourage the user to ignore the message, but give
advanced users the option to (a) view the certificate of the signer
and the entire certificate chain (if any) in order to help decide if
the signer should be trusted to send the message, and then (b) allow
CUA to accept and process the iCalendar object.
4. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized
to perform the operation as defined by [iTIP]. If the conditions are to perform the operation as defined by [iTIP]. If the conditions are
not met, ignore the message. not met, ignore the message.
5. If all the above conditions are met, the message can be processed. 4. If all the above conditions are met, the message can be processed.
[RFC-1847] signing also protects against malicious changes in [RFC-1847] signing also protects against malicious changes in
transit. transit.
If calendar confidentiality is required by the sender, signed iMIP If calendar confidentiality is required by the sender, signed iMIP
messages SHOULD be encrypted by a mechanism based on Security messages SHOULD be encrypted by a mechanism based on Security
Multiparts for MIME [RFC-1847]. Multiparts for MIME [RFC-1847].
Once a signed and/or encrypted iMIP message is received and Once a signed and/or encrypted iMIP message is received and
successfully verified (as detailed above) by a CUA, the CUA SHOULD successfully verified (as detailed above) by a CUA, the CUA SHOULD
remember whether the sender of the message is using signing and/or remember whether the sender of the message is using signing and/or
encrypting. If an unsigned iMIP message is received from the same encrypting. If an unsigned iMIP message is received from the same
sender later on, the receiving CUA SHOULD warn the receiving user sender later on, the receiving CUA SHOULD warn the receiving user
about a possible man-in-the-middle attack and SHOULD ignore the about a possible man-in-the-middle attack and SHOULD ignore the
message, unless explicitly overridden by the user. <<Should it also message, unless explicitly overridden by the user.
try to notify the other end?>>
Implementations MAY provide means for users to disable signing and Implementations MAY provide means for users to disable signing and
encrypting. encrypting.
It is possible to receive iMIP messages sent by someone working on It is possible to receive iMIP messages sent by someone working on
behalf of another "Calendar User". This is determined by examining behalf of another "Calendar User". This is determined by examining
the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
property. [iCAL] and [iTIP] provide no mechanism to verify that a property. [iCAL] and [iTIP] provide no mechanism to verify that a
"Calendar User" has authorized someone else to work on their behalf. "Calendar User" has authorized someone else to work on their behalf.
To address this security issue, implementations MUST provide To address this security issue, implementations MUST provide
skipping to change at page 12, line 24 skipping to change at page 12, line 24
Subject: Phone Conference Subject: Phone Conference
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:sman@netscape.example.com ORGANIZER:mailto:man@netscape.example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:sman@netscape.example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z DTSTART:19970701T210000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
DESCRIPTION:Please review the attached document. DESCRIPTION:Please review the attached document.
UID:calsvr.example.com-873970198738777 UID:calsvr.example.com-873970198738777
ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
skipping to change at page 18, line 37 skipping to change at page 18, line 37
This section outlines a series of recommended practices when using a This section outlines a series of recommended practices when using a
messaging transport to exchange iCalendar objects. messaging transport to exchange iCalendar objects.
5.1 Use of Content and Message IDs 5.1 Use of Content and Message IDs
The [iCAL] specification makes frequent use of the URI for data types The [iCAL] specification makes frequent use of the URI for data types
in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others.
Two forms of URIs are Message ID (MID) and Content ID (CID). These Two forms of URIs are Message ID (MID) and Content ID (CID). These
are defined in [RFC-2392]. Although [RFC-2392] allows referencing are defined in [RFC-2392]. Although [RFC-2392] allows referencing
messages or MIME body parts in other MIME entities or stores, it is messages or MIME body parts in other MIME entities or stores, it is
strongly recommended that iMIP implementations include all referenced strongly RECOMMENDED that iMIP implementations include all referenced
messages and body parts in a single MIME entity. Simply put, if an messages and body parts in a single MIME entity. Simply put, if an
iCalendar object contains CID or MID references to other messages or iCalendar object contains CID or MID references to other messages or
body parts, implementations should ensure that these messages and/or body parts, implementations should ensure that these messages and/or
body parts are transmitted with the iCalendar object. If they are body parts are transmitted with the iCalendar object. If they are
not, there is no guarantee that the receiving CUA will have the not, there is no guarantee that the receiving CUA will have the
access or the authorization to view those objects. access or the authorization to view those objects.
6 IANA Considerations 6 IANA Considerations
Registration of text/calendar MIME Media Type is done in [iCal]. Registration of text/calendar MIME Media Type is done in [iCal].
skipping to change at page 19, line 19 skipping to change at page 19, line 19
This document doesn't require any additional actions from IANA. This document doesn't require any additional actions from IANA.
7 References 7 References
7.1 Normative References 7.1 Normative References
[iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and [iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 5545. Scheduling Core Object Specification (iCalendar)", RFC 5545.
[iTIP] Daboo, C., "iCalendar Transport-Independent [iTIP] Daboo, C., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", work in progress, draft-ietf- Interoperability Protocol (iTIP)", RFC 5546.
calsify-2446bis-XX.txt (Updates RFC 2446)
[RFC-5322] Resnick, P., "Internet Message Format", RFC 5322, October [RFC-5322] Resnick, P., "Internet Message Format", RFC 5322, October
2008. 2008.
[MAILTO] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto URL [MAILTO] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto URL
scheme", RFC 2368, June 1998. scheme", RFC 2368, June 1998.
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
skipping to change at page 22, line 27 skipping to change at page 22, line 27
the calendar object is known to be transferred over 8-bit clean the calendar object is known to be transferred over 8-bit clean
transport. transport.
Clarified that file extension specified in the Content-Disposition Clarified that file extension specified in the Content-Disposition
header field is not to be used to override the Content-Type MIME header field is not to be used to override the Content-Type MIME
type. type.
Disallow use of "multipart/alternative" for slightly different Disallow use of "multipart/alternative" for slightly different
representations of the same calendar. representations of the same calendar.
Clarified handling of the "method" MIME parameter of the "Content-
Type" header field.
Clarified that in an iMIP message an ORGANIZER/ATTENDEE property
contains a mailto: URI.
Fixed examples with ATTENDEE property to use "CUTYPE=" instead of Fixed examples with ATTENDEE property to use "CUTYPE=" instead of
"TYPE=". "TYPE=".
Additional examples.
Improved Security Considerations section. Improved Security Considerations section.
Multiple editorial changes to different sections of the document. Multiple editorial changes to different sections of the document.
<<TBD>>
Appendix B. Acknowledgements Appendix B. Acknowledgements
<<RFC Editor: feel free to move this section elsewhere.>> <<RFC Editor: feel free to move this section elsewhere.>>
The editor of this document wish to thank Frank Dawson, Steve Mansour The editor of this document wish to thank Frank Dawson, Steve Mansour
and Steve Silverberg, the original authors of RFC 2447, as well as and Steve Silverberg, the original authors of RFC 2447, as well as
the following individuals who have participated in the drafting, the following individuals who have participated in the drafting,
review and discussion of this memo: review and discussion of this memo:
Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear. Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear,
Peter Saint-Andre.
 End of changes. 18 change blocks. 
45 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/