iCalendar Message-Based Interoperability Protocol (iMIP)
draft-ietf-calsify-rfc2447bis-11

[Ballot comment]
The Security Considerations text should be updated to reflect any changes that result from the discuss points
above.  Specifically, this specification will inherit many of the security considerations in pkix, s/mime and/or pgp
if the changes suggested are accepted and implemented.

[Ballot comment]
Section 1

  This binding document provides the transport specific information
  necessary to convey iCalendar Transport-independent Interoperability
  Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in
  [RFC-5322] and [RFC-2045].

What is a "binding document"? I think the document "specifies a
binding". But I don't think that the document is itself binding.

[Ballot comment]
Formatting comment - the Table of Contents does not fully match the document - page numbers are not accurate, Appendices missing, the last two sections listed in the table are actually no longer in the document, the capitalization of some of the sections does not correspond to the one in the document.

[Ballot discuss]
I'm not quite sure this issue is included in Sean's DISCUSS; if it is, I'll clear.  In section 3:

  If calendar confidentiality is required by the sender, signed iMIP
  messages SHOULD be encrypted by a mechanism based on Security
  Multiparts for MIME [RFC-1847].

s/SHOULD/MUST/, or give some explanation about the alternatives to providing confidentiality if "a mechanism based on Security Multiparts for MIME" is not used.

[Ballot comment]
The Security Considerations text should be updated to reflect any changes that result from the discuss points
above.  Specifically, this specification will inherit many of the security considerations in pkix, s/mime and/or pgp
if the changes suggested are accepted and implemented.

[Ballot discuss]
I know we are updating a rather old document, and we may not be able to apply the same metrics that would
be appropriate for new work.  That said, there are some opportunities to fill in holes here, and I would like the
author to consider which are appropriate to address at this point.

The document points to 1847 to achieve authentication and confidentiality.  However, this is just a framework
document and does not specify specific signature types or encryption mechanisms.  In addition to the algorithms
and key sizes that Sean mentioned in his discuss, there are a few additional features that could be specified to
enhance interoperability.  Given the age of the protocol, I would hope that a de facto standard for each feature
has already emerged; this should definitely be factored in to the selection process.

The first would be signature type.  When RFC 1847 was being published, the application/moss-signature specified
in RFC 1848 was the obvious choice.  More current protocols would specify application/pgp-signature or
application/x-pkcs7-signature.  Could we specify one of these as mandatory to implement?

A similar choice for encryption might be in order.  The application/pgp-encrypted and application/pkcs7-mime
types are two possibilities, I think.

The third feature that I found missing was formats and processing rules for certificates.  Section 2.2.2 explicitly
calls out "public/private key certificates".  Both PGP and PKIX references would seem to be in order here.  (Even
if one is selected as mandatory to implement, the other remains an option.)  Establishing rules for validation and
use of these certificates seems foundational, and since we can do it by reference I think it ought to be added.

[Ballot comment]
1) Sec 2.1: Should htere be a pointer to [iCAL] after text/multipart (you don't find out until the IANA section that that's where it's from):

OLD:

  A MIME entity containing content information formatted according to
  this document will be referenced as a "text/calendar" content type.

NEW:

  A MIME entity containing content information formatted according to
  this document will be referenced as a "text/calendar" content type [iCAL].

2) Sec 2.1.1: Should the must be MUST in the following:

  That is, the "Organizer"
  must ignore an [iTIP] message from spoof@xyz.example.net that
  declines a meeting invitation for b@example.com.

3) In Sec 2.2.2, the last sentence is confusing to me.  Aren't you really trying to say unauthenticated messages may not be reliable?

OLD:

Authenticating an unsigned message may not be reliable.

NEW:

Unauthenticated messages (i.e., unsigned messages) may not be reliable.

4) To align with 2.2.2, change 2.2.3 to explicitly call out multipart/encrypted:

OLD:

To ensure confidentiality using iMIP implementations should utilize encryption compliant with [RFC-1847].

NEW:

To ensure confidentiality using iMIP implementations should utilize "multipart/signed" from [RFC-1847].

Note that if DISCUSS #1 is agreed then the r/should/MUST.

5) Sec 2.2.3 (for clarity):

OLD:

The protocol does not restrict ...

NEW:

iMIP does not restrict ...

6) Sec 2.4 bullet #1:  Shouldn't we add a reference after multipart/mixed to RFC 2046:

OLD:

  Note 1: A MIME message containing multiple iCalendar objects with
  different method values MUST be further encapsulated with a
  "multipart/mixed" MIME entity.

NEW:

  Note 1: A MIME message containing multiple iCalendar objects with
  different method values MUST be further encapsulated with a
  "multipart/mixed" MIME entity [RFC-2046].

7) Sec 2.4: Add reference to RFC 2046:

OLD:

...  scheduling message (i.e., "multipart/alternative").

NEW:

...  scheduling message (i.e., "multipart/alternative" [RFC-2046]).

8) Sec 3: Provide pointer back to 2.2.2 and 2.2.3:

OLD:

  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.

NEW:

  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 (see Section 2.2.2 and 2.2.3).

9) Sec 3 bullet 1 (for clarity): replace:

who signed the email message

with

who signed the text/calendar body part

[Ballot discuss]
1) Section 2.2.2 and 2.2.3 say that authentication "can" be applied with multipart/signed and confidentiality "should" utilize mutlipart/encrypted.  Shouldn't these be MUSTs?  It's MUST in the security considerations section, but I think it ought to be MUST here too (i.e., r/can/MUST and r/shoud/MUST).

2) Specify MUST support multipart/signed and multipart/encrypted is not sufficient to ensure interoperability.  You need to pick an algorithm for message digest, digital signatures, and encryption.  Might I suggest: SHA-256, RSA 2048 (for both sig and enc).

3) Sec 3 Step 3:  How is this done: If the signer cannot be correlated to an "ATTENDEE"/"ORGANIZER" property?  If you're using the email address in the certificate then you need to say whether the email address is required in the certificate and where it should be located.  Also, shouldn't there be a reference to RFC 5280 for certificate path processing?

[Ballot comment]
From the writeup, this is intended to Obsolete 2447 - please add the Obsoletes: line in the header.

There's some text in the "Status of this Memo" section indicating the intent at one point was to
take iMIP to Draft with this document (" A revised version of this draft document will be submitted to the RFC editor as a Draft Standard for the Internet Community. ") Just to double-check - it's being process for recycling at Proposed Standard at the moment, not for moving to Draft.

IANA Last Call Comments:

IANA understands that, upon approval of this document, there no IANA
Actions that need to be completed. In particular, IANA notes that the
text/calendar media type is already registered in the Media Types registry.