Blake Ramsdell <blake(_at_)sendmail(_dot_)com> writes:
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.
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.