ietf-smime
[Top] [All Lists]

Re: AW: Content Type for XML Objects

2008-04-08 11:37:41

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

At 12:42 PM 4/8/2008, Jörg Schwenk wrote:
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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] Im
Auftrag von Russ Housley
Gesendet: Freitag, 4. April 2008 18:04
An: Lisa Dusseault
Cc: ietf-smime(_at_)imc(_dot_)org; Chris(_dot_)Newman(_at_)sun(_dot_)com
Betreff: Re: Content Type for XML Objects


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

At 11:39 AM 4/4/2008, Lisa Dusseault wrote:
>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
>