Subject: [ietf-types] Review of application/ccmp+xml

From: Alan Johnston <[email-masked]>
Date: Thu, 16 Sep 2010 14:03:53 -0500

Hi,

I would like to request a review of the application/ccmp+xml MIME type,
registered in Section 12.3 of draft-ietf-xcon-ccmp-07:

     http://tools.ietf.org/html/draft-ietf-xcon-ccmp-10

The document has completed WGLC in the XCON Working Group.

Thanks,
Alan Johnston
co-chair XCON WG

- - - -

12.3. MIME Media Type Registration for 'application/ccmp+xml'

   This section registers the "application/ccmp+xml" MIME type.

   To:  [email-masked]
   Subject:  Registration of MIME media type application/ccmp+xml
   MIME media type name:  application
   MIME subtype name:  ccmp+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the character encoding of enclosed XML for which the
      default is UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], section 3.2.
   Security considerations:  This content type is designed to carry
      protocol data related conference control.  Some of the data could
      be considered private and thus should be protected.
   Interoperability considerations:  None.
   Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]
   Applications which use this media type:  Centralized Conferencing
      control clients and servers.
   Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:  Mary
      Barnes <[email-masked]>
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information:  This media type is a specialization of
      application/xml [RFC3023], and many of the considerations
      described there also apply to application/ccmp+xml.

---

From: Ned Freed <[email-masked]>
Date: Sat, 18 Sep 2010 14:54:59 -0700 (PDT)

>       3023 [RFC3023], section 3.2.

What you have here is OK, but I note that all of the examples in the draft use
utf-8 and have the charset embedded in the content. If utf-8 is all that's ever
used, perhaps it would be better just to state that and get rid of all the
variability here.

>       be considered private and thus should be protected.

You also need to state whether or not the media type contains executable
content, and if it does explain how to handle it safely. (I suspect the
answer is no, but it still needs to be explicit.) 

See below for one more omission that needs correction.

You say "should be protected". THe implicaion is the media type itself doesn't
provide this capability. If that's indeed the case, it would be better to state
this in so many words. It would also be helpful to say whether or not integrity
protection is needed, and if it is, how best to provide it.

>       described there also apply to application/ccmp+xml.

THis is too vague in such a general context to be useful. OTOH, this is
an important security consideration, so I suggest moving this to the sec
cons section where it will be specifically about security. A reference to
RFC 3023 section 10 would also help.

				Ned
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 19 Sep 2010 00:24:01 +0200

>   To:  [email-masked]

(There is no need to include that.)

>   MIME subtype name:  ccmp+xml

This is based on an outdated template; the latest version can be found
in RFC 4288, it uses a couple of different field names and organizes
them slightly differently.

>      Indicates the character encoding of enclosed XML for which the

(That is the overall default if no other encoding information can be
found; it is not, however, the default value of the charset parameter).

>      3023 [RFC3023], section 3.2.

RFC 3023 (section 7.1) recommends particular language to use here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 19 Sep 2010 00:30:15 +0200

>used, perhaps it would be better just to state that and get rid of all the

The charset parameter (and defining it exactly as it is defined for the
application/xml media type) is necessary if you want implementations of
only this type agree with general purpose software on what the encoding
is. Disagreement about what the character encoding is is a typical se-
curity vulnerability.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Sat, 18 Sep 2010 18:18:37 -0700 (PDT)

> is. Disagreement about what the character encoding is is a typical se-
                                                                               
I'm sorry, but I believe a much bigger potential security vulnerability is
introduced by the potential of there being a silly state difference between the
character encoding listed in the XML proper and what's in the charset
parameter.

In other words, I believe the suggestions given in RFC 3023 are seriously off
the mark.

But the way to migitate all of this is to Just Use UTF-8. Which is why I wrote
what I wrote - there is no need for a parameter if only one charset is allowed.

				Ned

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 19 Sep 2010 03:46:27 +0200

>character encoding listed in the XML proper and what's in the charset

The problem can be avoided by avoiding the +xml convention. For +xml
types the problem exists whether or not the registration includes a
charset parameter.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Sun, 19 Sep 2010 08:44:06 -0700 (PDT)

> types the problem exists whether or not the registration includes a

On the contrary, you cannot assume +xml will be recogized and confer special
processing onto an otherwise unknown type. And a type may be recognized by name
and processed as XML, along with its charset parameter, even without +xml being
part of the name. So at most the +xml MAY result in a silly state causing a
problem; the absence of +xml in no way can be assumed to prevent such problems
from occurring.

I should also point out that I see nothing in RFC 3023 that says the presence
of +xml means a charset parameter is meaningful on a given subtype. The only
mechanism in MIME that can associate a parameter with an entire group of
subtypes is the primary type, e.g., a charset parameter on a text type always
has the same meaning. We're talking about application types here, which don't
have such semantics.

				Ned