[Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt
TimHare at comcast.net
Mon Jun 9 19:02:35 PDT 2008
" 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
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.
"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.
Interested Bystander, Non-Inc.
From: ietf-calsify-bounces at osafoundation.org
[mailto:ietf-calsify-bounces at osafoundation.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: Monday, June 09, 2008 2:00 PM
To: i-d-announce at ietf.org
Cc: ietf-calsify at osafoundation.org
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts
This draft is a work item of the Calendaring and Scheduling Standards
Simplification Working Group of the IETF.
Title : iCalendar Message-Based Interoperability Protocol
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:
A URL for this Internet-Draft is:
Internet-Drafts are also available by anonymous FTP at:
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
More information about the Ietf-calsify