rfc2447.txt

RFC 的详细文档！


RFC 2447                          iMIP                     November 1998


3 Security Considerations

   The security threats that applications must address when implementing
   iTIP are detailed in [iTIP]. Two spoofing threats are identified:
   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 attachments using a mechanism based on
   Security Multiparts for MIME [RFC-1847] to facilitate the
   authentication the originator of the iCalendar object.
   Implementations MAY provide a means for users to disable signing and
   encrypting. The steps are described below:

   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update or the "Attendee" sending a reply.

   2. Using the [RFC-1847]-compliant security mechanism, 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 an "ATTENDEE" property in the iCalendar
   object. If the signer cannot be correlated to an "ATTENDEE" property,
   ignore the message.

   4. Determine whether or not the "ATTENDEE" is authorized to perform
   the operation as defined by [iTIP]. If the conditions are not met,
   ignore the message.

   5. If all the above conditions are met, the message can be processed.

   To address the confidentiality security threats, signed iMIP messages
   SHOULD be encrypted by a mechanism based on Security Multiparts for
   MIME [RFC-1847].

   It is possible to receive iMIP messages sent by someone working on
   behalf of another "Calendar User". This is determined by examining
   the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
   property.  [iCAL] and [iTIP] provide no mechanism to verify that a
   "Calendar User" has authorized someone else to work on their behalf.
   To address this security issue, implementations MUST provide
   mechanisms for the "Calendar Users" to make that decision before
   applying changes from someone working on behalf of a "Calendar User".






Dawson, et. al.             Standards Track                     [Page 7]

RFC 2447                          iMIP                     November 1998


4 Examples

4.1 Single Component With An ATTACH Property

   This minimal message shows how an iCalendar object references an
   attachment. The attachment is accessible via its URL.

   From: [e-mail]
   To: [e-mail]
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:[e-mail]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[e-mail]
   ATTENDEE;RSVP=YES:mailto:[e-mail]
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Please review the attached document.
   UID:calsvr.example.com-873970198738777
   ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2 Using Multipart Alternative for Low Fidelity Clients

   This example shows how a client can emit a multipart message that
   includes both a plain text version as well as the full iCalendar
   object.  Clients that do not support text/calendar will still be
   capable of rendering the plain text representation.

   From: [e-mail]
   To: [e-mail]
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360"

   --01BD3665.3AF0D360
   Content-Type: text/plain;charset=us-ascii



Dawson, et. al.             Standards Track                     [Page 8]

RFC 2447                          iMIP                     November 1998


   Content-Transfer-Encoding: 7bit

   This is an alternative representation of a TEXT/CALENDAR MIME Object
   When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
   Where:
   Organizer: [e-mail]
   Summary: Phone Conference

   --01BD3665.3AF0D360
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:[e-mail]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[e-mail]
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:[e-mail]
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T170000Z
   DTEND:19970701T173000Z
   SUMMARY:Phone Conference
   UID:calsvr.example.com-8739701987387771
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --01BD3665.3AF0D360

4.3 Single Component With An ATTACH Property and Inline Attachment

   This example shows how a message containing an iCalendar object
   references an attached document. The reference is made using a
   Content-id (CID). Thus, the iCalendar object and the document are
   packaged in a multipart/related encapsulation.

   From: [e-mail]
   To: [e-mail]
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type: multipart/related; boundary="boundary-example-1";
                 type=text/calendar

   --boundary-example-1




Dawson, et. al.             Standards Track                     [Page 9]

RFC 2447                          iMIP                     November 1998


   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:[e-mail]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[e-mail]
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:[e-mail]
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T180000Z
   DTEND:19970701T183000Z
   SUMMARY:Phone Conference
   UID:calsvr.example.com-8739701987387771
   ATTACH:cid:[e-mail]
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --boundary-example-1
   Content-Type: application/msword; name="FieldReport.doc"
   Content-Transfer-Encoding: base64
   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <[e-mail]>

   0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////

   --boundary-example-1--

4.4 Multiple Similar Components

   Multiple iCalendar components of the same type can be included in the
   iCalendar object when the METHOD is the same for each component.

   From: [e-mail]
   To: [e-mail]
   Subject: Summer Company Holidays
   Mime-Version: 1.0
   Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.vcs"





Dawson, et. al.             Standards Track                    [Page 10]

RFC 2447                          iMIP                     November 1998


   BEGIN:VCALENDAR
   PRODID:-//ACME/DESKTOPCALENDAR//EN
   METHOD:PUBLISH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:[e-mail]
   DTSTAMP:19970611T150000Z
   DTSTART:19970701T150000Z
   DTEND:19970701T230000Z
   SUMMARY:Company Picnic
   DESCRIPTION:Food and drink will be provided
   UID:CALSVR.EXAMPLE.COM-873970198738777-1
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   BEGIN:VEVENT
   ORGANIZER:MAILTO:[e-mail]
   DTSTAMP:19970611T190000Z
   DTSTART:19970715T150000Z
   DTEND:19970715T230000Z
   SUMMARY:Company Bowling Tournament
   DESCRIPTION:We have 10 lanes reserved
   UID:CALSVR.EXAMPLE.COM-873970198738777-2
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.5 Multiple Mixed Components

   Different component types must be encapsulated in separate iCalendar
   objects.

   From: [e-mail]
   To: [e-mail]
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"

   This is a multi-part message in MIME format.

   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event1.vcs"






Dawson, et. al.             Standards Track                    [Page 11]

RFC 2447                          iMIP                     November 1998


   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:[e-mail]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[e-mail]
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:[e-mail]
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss what happened at the last meeting
   UID:calsvr.example.com-8739701987387772
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding:7bit
   Content-Disposition: attachment; filename="todo1.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   DUE:19970701T090000-0700
   ORGANIZER:mailto:[e-mail]
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:[e-mail]
   ATTENDEE;RSVP=YES:mailto:[e-mail]
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss a new location for the company picnic
   UID:calsvr.example.com-td-8739701987387773
   SEQUENCE:0
   STATUS:NEEDS ACTION
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C









Dawson, et. al.             Standards Track                    [Page 12]

RFC 2447                          iMIP                     November 1998