ietf-smime
[Top] [All Lists]

AW: Content Type for XML Objects

2008-04-08 10:20:25
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


Attachment: smime.p7s
Description: S/MIME cryptographic signature