End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
draft-ietf-xmpp-e2e-09

[Ballot discuss]
In section 6.3, says that the subjectAltName in a certificate SHOULD
  contain a 'im:' URI a 'pres:' URI of the user.  This is fine.  Then, it
  says that the 'from' attribute SHOULD match the URI in the certificate.
  I prefer a MUST statement.  Something like: If the certificate contains
  a URI, then it MUST match the 'from' attribute.  Of course, the final
  document text must include the exception text.

  In the last paragraph of section 6.3, the certificate syntax does not
  support the suggested use of otherName.  Name forms are identified by
  object identifiers, not ASCII strings.

  Section 6.9 does not provide a key management algorithm for EnvelopedData.
  Also, not all of the algorithms listed are specified in [CMS-ALG].  I
  propose the following replacement text:

    6.9  Mandatory to Implement Cryptographic Algorithms

    All implementations MUST support the following algorithms.
    Implementations MAY support other algorithms as well.

    For CMS SignedData:

    - the SHA-1 message digest as specified in [CMS-ALG] section 2.1.

    - the RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as
      specified in [CMS-ALG] section 3.2.

    For CMS EnvelopedData:

    - the RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
      section 4.2.1.

    - the AES-128 encryption algorithm in CBC mode, as specified in
      [CMS-AES].

    { Note: [CMS-AES] is a new reference to RFC 3565. }

  I expected section 6 to say something about the correct processing of
  messages with invalid digital signatures, messages that cannot be
  decrypted, and messages that appear to be replayed.  The only situation
  that seems to be addressed is when the name in the certificate does not
  match the name in the message.

[Ballot comment]
Please change the title of the document to reflect the support of digital
  signatures as well as encryption.

  Please delete section 1.2 prior to publication as an RFC.

  The section headings for section 3 and section 4 are misleading.  I
  expected to see discussion of encryption, but the sections are about
  digital signatures.

  [CERT] should point to draft-ietf-smime-rfc2632bis-*, which is in the
  RFC Editor queue.

  [CMC] is pointing to the wrong document.  It should be a reference to
  RFC 2797.  Also, this should be an informative reference, not a
  normative one.

  [CMP] should be an informative reference, not a normative one.

  [CMS] should point to draft-ietf-smime-rfc3369bis-*, which is in the
  RFC Editor queue.

  [SMIME] should point to draft-ietf-smime-rfc2633bis-*, which is in the
  RFC Editor queue.

  I think [XML] should be an informative reference, not a normative one.

[Ballot discuss]
What is the proper error reply when a node receives a message it can't decrypt?  Are there standard error replies for the error conditions (i.e., timestamp failure) described in this document?

[Ballot comment]
Is some mechanism necessary by which a node can ascertain if the remote end supports this mechanism?  What is the proper reply by a node that receives a

Section 1.3 (Intellectual Property Notice) of this document should be removed and instead sent to the IETF for inclusion on the IPR notice page:

http://www.ietf.org/ipr.html

The [XML-REG] reference is now RFC 3688.

Section 9.1: has the media type description been sent to the IETF-types list for review and comment?  I would also refer to section 8 in the "security considerations" portion of the template.

Section 9.2: the registrant must be something more stable than an IETF working group.  RFC 3688 says "In the case of IETF developed standards, the Registrant will be the IESG".

Section 9.2: how will revisions to the elements in the namespace be supported over time?  I've been bugging document authors lately about a lack of text describing how versioning will be addressed; this document is also missing detail describing what happens in the future if something needs to change.  Will a new namespace be needed?  How will backwards compatibility be addressed if/when the namespace changes?