The Atom Syndication Format
draft-ietf-atompub-format-11

[Ballot discuss]
My discuss overlaps with Russ's discuss but I'm asking for more than
he believes is necessary so I'm filing my own discuss.  The current
text allows documents to be encrypted but not integrity protected.


Allowing encryption without integrity protection allows encrypted
documents to be modified by an attacker in ways predictable to the
attacker.  The only sign of modification for the algorithms being
used here will be one garbled block; this can be hidden in various
ways.
I believe this creates a security problem because it violates the
principle of least surprise.  People who send encrypted content
understand that if they don't sign it, someone else can send
different encrypted content instead.  However people assume that
since an attacker cannot read their encrypted content they cannot
modify it in predictable ways.

Other messaging formats within the IETF do not solve this problem.
Russ claims that S/MIME is vulnerable to this attack.  I think PGP
is vulnerable although the analysis is harder because of how PGP is
used and because it uses CFB not CBC.

I believe this problem is relatively easy to fix.  So I believe the
atom document needs to mandate a fix even though we have decided for
some older formats that the problem didn't need to be fixed there.
There seem to be three possible solutions all of reasonable
complexity given that encryption is supported at all:

* Require signatures whenever encryption is used.  The signature
needs to be on the plaintext not the ciphertext.  It is OK for the
signature to be made with a self-signed certificate or fresh public
key; the verifier need only verify the signature not (in this
instance) the certificate.

* Allow the document to use the xmldsig MAC operation.  The key
management needs to be  the same as for the encryption.  The mac
needs to be of the plaintext not ciphertext.

* Include a hash of the plaintext of the document within the
document.  Minimal algorithm negotiation is needed.

The first option is probably easiest but will make anonymous
encryption hard.  The second option is in some sense the best but
involves the most complexity.  The third option seems relatively
easy to implement although a bit tricky to specify.  The third
option allows for anonymous encryption like the second.

[Ballot discuss]
Section 5 does not provide sufficient detail for interoperability.
  Unfortunately, the complexity of XML and the variety of contexts in
  which it is used made it impossible for the XMLDSIG WG to come up
  with one set of canonicalization rules that are "distinguished."
  By distinguished, I mean that there is exactly one way to represent
  the XML object.  There are two canonicalization rule sets: the
  Canonical XML and the Exclusive XML Canonicalization.  Specify
  which one is mandatory-to-implement.

  Section 5 should tell the reader when the use of digital signatures
  and encryption are desirable.  Also, I would like to see mandatory-
  to-implement algorithms specified.  If appropriate, use MUST- and
  SHOULD+ as they were defined by the IPsec WG to tell implementors
  about future algorithm requirements.

  In section 5, please state the order of the nesting if both digital
  signature and encryption are used.  I believe that signing the
  plaintext is the correct ordering in this situation.

  Since XML encryption does not provide integrity, it is important to use
  XML digital signature whenever encryption is used.  When a digital
  signature algorithm is used, this should be straightforward; however,
  the XML digital signature specification also supports message
  authentication codes (MACs).  When MACs are used, the symmetric keys
  for the encryption and the MAC calculation need to use the same key
  management technique.  When digital signatures are used, the recipient
  must have a way to verify the public key of the signer.  This is
  usually done with a certificate.

  Section 8.5 needs to be expanded.  When digital signature or encryption
  are used, what threats do they protect against?

[Ballot discuss]
There are several places in the document where the text talks about dereferencing IRIs
(see, for example 4.2.4).  While I believe I understand the shorthand here, we need to
be somewhat careful in how we describe this.  For HTTP, as an example, any IRI that
did not also conform to the URI spec (that is to RFC 3986/STD 66) would have to go
through the mapping steps in RFC 3987, section 3.1, before dereferencing.  This
is true for any protocol which does not support IRIs natively.  I believe that this needs
to be highlighted in the document and the text on dereferencing shifted to "dereferencing
the URI".

Please understand that I have no objections to the use of IRIs as identifiers here,
and I believe that the IRI comparison rules are fine.  But for protocol processing,
which is what "dereferencing" will imply to most readers, current schemes use URIs
as described in 3986; we need to make that clear so that the work in 3987 on
how to do the mapping gets invoked correctly.

[Ballot discuss]
There are several places in the document where the text talks about dereferencing IRIs
(see, for example 4.2.4).  While I believe I understand the shorthand here, we need to
be somewhat careful in how we describe this.  For HTTP, as an example, any IRI that
did not also conform to the URI spec (that is to RFC 3986/STD 66) would have to go
through the mapping steps in RFC 3987, section 3.1, before dereferencing.  This
is true for any scheme which does not support IRIs natively.  I believe that this needs
to be highlighted in the document and the text on dereferencing shifted to "dereferencing
the URI".

Please understand that I have no objections to the use of IRIs as identifiers here,
and I believe that the IRI comparison rules are fine.  But for protocol processing,
which is what "dereferencing" will imply to most readers, current schemes use URIs
as described in 3986; we need to make that clear so that the work in 3987 on
how to do the mapping gets invoked correctly.

[Ballot discuss]
There are several places in the document where the text talks about dereferencing IRIs
(see, for example 4.2.4).  While I believe I understand the shorthand here, we need to
be somewhat careful in how we describe this.  For HTTP, as an example, any IRI that
did not also conform to the URI spec (that is to RFC 3986/STD 66) would have to go
through the mapping steps in RFC 3987, section 3.1, before dereferencing.  This
is true for any scheme which does not support IRIs natively.  I believe that this needs
to be highlighted in the document and the text on dereferencing shifted to "dereferencing
the URI".

Please understand that I have no objections to the use of IRIs as identifiers here, but
for protocol processing, current schemes use URIs as described in 3986; we need to
make that clear so that the work in 3987 on how to do the mapping gets invoked
correctly.

[Ballot comment]
The document says:

3.1.1  The "type" Attribute

  Text constructs MAY have a "type" attribute.  When present, the value
  MUST be one of "text", "html" or "xhtml".  If the "type" attribute is
  not provided, Atom Processors MUST behave as though it were present
  with a value of "text".  MIME media types [MIMEREG] MUST NOT be used
  as values for the "type" attribute.

and Later:

4.1.3.1  The "type" attribute

  On the atom:content element, the value of the "type" attribute MAY be
  one of "text", "html", or "xhtml".  Failing that, it MUST be a MIME
  media type, but MUST NOT be a composite type (see Section 4.2.6 of
  [MIMEREG]).  If the type attribute is not provided, Atom Processors
  MUST behave as though it were present with a value of "text".

While I understand that the 4.1.3.1 text applies to atom:content rather
than more generally, given the MUST NOT vs. MUST here I strongly encourage
some further efforts to clarify this apparent contradiction.    The first could have a
forward pointer to the second as a note, the second to the first as a note, or the names
could be disambiguated in some way.  I don't see this as blocking, but I believe it
would be very useful to get this somewhat clearer.

IANA Last Call Comments:
Upon approval of this document the IANA will register the MIME media type application/atom+xml.  A Registry of Link Relations will be created and will include the five initial values described in this document.

Some additional words are needed in the IANA Considerations section to help guide the IESG in the attribute value approval process, but that can wait until after IETF last call.  Explicit mention of internationalization considerations might be needed, but I'll leave that to see what the community has to say.

AD Review Comments/Questions:

The document includes an informative RELAX NG schema and several examples.  What has been done to confirm that the schema is free of errors and that all of the examples given in the document are valid according to the schema?  (I could check an XML Schema myself, but I don't have the tools I need to check RELAX NG.)

Sections 1.1, 1.2: RFC 3688/BCP 81 describes IETF practice for naming XML namespaces.  Why are namespace URIs (such as http://purl.org) that don't conform to this practice being used?

Section 1.2: please reference draft-crocker-abnf-rfc2234bis-00.txt instead of RFC 2234 and confirm that everything that was valid before is still valid.  The IESG approved this document as a Draft Standard last week.

Section 2 describes a requirement for well-formedness, but it doesn't mention validity.  I suspect that validity isn't a requirement given that the RELAX NG schema is informative, but it would be better if a specific statement were included to note that validity is not a requirement.

Section 4: RFC 2045 is referenced.  2045 is on its way to being obsoleted by draft-freed-mime-p4 (in the RFC Editor queue) and draft-freed-media-type-reg (in last call).  Can the more recent documents be referenced instead of 2045?

The MIME media type registration template included in section 7 MUST be submitted to the ietf-types list (ietf-types@alvestrand.no) for review.  A two-week review period is standard for requests to register new types in the standards tree.  Please see the list archives [1] for samples if help is needed in crafting a review request and please send the request ASAP.

Section 7.1: what process is the IESG supposed to use to review registration requests?  Please see section 2 of RFC 2434/BCP 26 for mechanisms that might be used and please specify one in the document.

-Scott-

[1]
http://eikenes.alvestrand.no/pipermail/ietf-types/