Subject: Re: Content Type for XML Objects

From: Lisa Dusseault <[email-masked]>
Date: Fri, 4 Apr 2008 08:39:43 -0700

In apps, we've had the practice of defining different MIME types for  
different kinds of XML-formatted data.  A custom MIME type can often  
tell you much more than just what the formatting is, of course.  This  
is most frequently seen in documents that might be sent over HTTP,  
where filtering or dispatching (to a Web application, for example) can  
possibly be done on the MIME type alone.  However there's always the  
fallback to application/xml which may or may not be allowed depending  
on the context.  E.g. the W3C says that XHTML documents SHOULD be  
given the content type "application/html+xml" when returned to  
clients, although of course a Web server could return other XML  
documents as application/xml.

The convention is to put "+xml" on the end of the MIME type -- I don't  
know if it's very common for implementations to use that convention to  
tell that the document is in XML even when the specific MIME type is  
not known.

Whether this approach would be worth it in CMS as well, I can't tell.  
Looking at RFC2984, OIDs seem to be about cryptographic functions, not  
content objects.  What am I missing?

Lisa

On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:

> I have received a request to assign an Object Identifier (OID) to be  
> used as a content type for XML objects.  The idea is that one would  
> look inside the XML object to determine  the type of XML object that  
> is being carried inside CMS.
>
> Is this the right thing to do?
>
> Would it be better to have a different content type for each XML  
> object?
>
> Would it be better to use id-data?
>
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 04 Apr 2008 12:04:09 -0400

Lisa:

IN CMS OIDs are used for many different things.  OIDs are used to 
identify algorithms, but they are also used to identify content 
types.  We have assigned OIDs for varios "protecting" content types 
to allow layering of secuity envelopes, and we have assigned OIDs for 
various contents.

In the most common case (id-data), then content type does not say 
anything.  In S/MIME, this content type is used, and it really means 
look inside for a MIME type.  The MIME type then tells the 
application how to handle the content.

In the request that I have received, the XML object is being signed 
directly.  That is, there is no MIME encoding of the XML object prior 
to signature.

Russ

---

From: Jörg Schwenk <[email-masked]>
Date: Tue, 8 Apr 2008 18:42:17 +0200

I think the problem is a little more complex:

- If you have to (re-)compute a hash value, you need the bitwise identical
representation of the signed data.

- ASN.1, MIME and XML have different methods how to guarantee this; In XML,
it is a process called canonicalization (C14N) that takes care e.g. of
linebreaks, but also of more complicated stuff like namespaces.

- The problem now is that there are, up to my knowledge, at least two
different C14N algorithms specified. So one OID will not do, because it has
to tell the signature verification function how to process the XML data
before hashing it.

- We also cannot rely on the XML data to carry this information: This is
e.g. not part of a simple XHTML document.

To sum up: I think we need a different OID for each C14N algorithm. To start
with one is OK, but then the C14N variant must be fixed.

Joerg

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Russ Housley
Gesendet: Freitag, 4. April 2008 18:04
An: Lisa Dusseault
Cc: [email-masked]; [email-masked]
Betreff: Re: Content Type for XML Objects

Lisa:

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 08 Apr 2008 14:10:56 -0400

Jörg:

I agree with all of you observations, but I do not agree with your conclusion.

When CMS is used to encapsulate a content, the content is carried as 
an OCTET STRING, so it is not altered.  Canonicalization is not an 
issue.  When CMS is used for a detached content, all of the 
canonicalization issues come out, but it is not the job of the 
content type to provide encoding rules.  The detached content must be 
transferred in a manner that the same hash value can be 
computed.  That cannot fall on the assignment of a CMS content type 
object identifier.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 09 Apr 2008 18:31:03 +1200

>to tell the signature verification function how to process the XML data

Argh, no, this is exactly the same mistake that XMLdsig makes, and (one of)
the reasons why it's such a nightmare to implement (see
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt for the short form and
http://seattle.toorcon.org/2007/talks/bradhill.ppt for the version with full
orchestration and five part harmony).

The nice thing about S/MIME and PGP is that what's signed is "this string of
bits, exactly as is", without any need to perform impossible manipulations on
it first like XMLdsig requires.

>To sum up: I think we need a different OID for each C14N algorithm.

Only if we want to repeat XMLdsig's mistakes.  This is a chance to fix them,
not to perpetuate them.

Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 9 Apr 2008 00:12:35 -0700

I agree with at least part of what Peter said.

This is the path that I think should be followed:

1.  There should be one XML content type OID assigned.  There are not
multiple ways to encode XML at this point.

2.  It should be determined 
        a) We need an authenticated attribute to convey what the XML is and
        b) if the ContentHints attribute is 

	If the answers are yes and no, then a new authenticated attribute
should be created for this purpose.

3.  For those people who want to continue using C14N algorithms on XML
trees, they need to define one or more new hash algorithms that convert an
XML tree into a binary number.  These new hash algorithms would most likely
take as a parameter one of the existing string to binary number hash
algorithms we are familiar with today.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Gutmann
> Sent: Tuesday, April 08, 2008 11:31 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: AW: Content Type for XML Objects
> 
>

---

From: Blake Ramsdell <[email-masked]>
Date: Wed, 9 Apr 2008 00:19:37 -0700

> it first like XMLdsig requires.

One way to avoid this temptation is to just leave it as "throw a MIME
Content-Type at the beginning of it with application/(something)+xml, mark it
id-data and call it S/MIME". The overhead does not seem significant (just the
additional header), and I don't know the utility of being able to identify it
as XML at the outer CMS wrapper.

It also, of course, neatly sidesteps any issues relating to "the C word" since
it is already steeped in current practice to just leave the poor guy's bits
alone, as Peter points out.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 09 Apr 2008 19:44:37 +1200

>as XML at the outer CMS wrapper.

Actually if the decision does end up being made to go with a non-id-data OID,
there's no reason why it has to be the same format as id-data.  So instead of
it being:

  Data ::= OCTET STRING

make it:

  XmlData ::= SEQUENCE {
  	version    INTEGER (0),
  	xmlInfo    UTF8String,
  	content    OCTET STRING
  	}

where 'xmlInfo' is whatever's needed to process the 'content'.  This does away
with the need to stick a MIME header around the XML data, which is a bit of an
artificial construct.  It also avoids a problem where what's being created
here is really a CMS type and not an S/MIME type, many CMS applications don't
do S/MIME so they couldn't do much with a Content-Type.

Or you could make the 'content' another UTF8String to make it explicit that
the content is supposed to be text, but I'm not sure how much variation XML
allows in its content, i.e. whether it would fall outside UTF8.  The 
advantage of 'OCTET STRING' is that it lets you take the XML content 
exactly as you see it and encapsulate it within a CMS blob without any need
for recoding.

(The other advantage with the 'xmlInfo' out-of-band data is that it's then
someone else's problem to standardise what goes in there, I'm not sure whether
CMS/SMIME should have to define formatting standards for XML content).

Peter.

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Apr 2008 14:37:31 -0400

>as XML at the outer CMS wrapper.

I already proposed this before starting this thread.  This is the 
response I got:

 > Gah, please not MIME encoding.  We already have to have ASN.1 and XML
 > libraries, I don't want to have to add a MIME library too.

As you can see, there is a strong preference to carry the XML object 
directly in CMS.

Russ

---

From: Blake Ramsdell <[email-masked]>
Date: Wed, 9 Apr 2008 13:17:51 -0700

On Wed, Apr 09, 2008 at 02:37:31PM -0400, Russ Housley wrote:
>  I already proposed this before starting this thread.  This is the response I 
>  got:
> 

I would be very surprised to find a CMS implementation that didn't have at
least a little bit of MIME in it. But the point is taken.

Blake

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Apr 2008 09:07:03 -0400

>As you can see, there is a strong preference to carry the XML object 

There are strong preferences all over on topics relating to XML. See 
the Apps Area mailing list, about once a year or so.

FWIW, I agree with Blake. Using the outer wrapper to say "the bits 
inside this are serialized as XML" doesn't seem useful to the S/MIME 
processor. Let's not reinvent MIME in our OIDs if we don't need to.