[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-04-30 14:21:40

-----Original Message-----
From: Paul Hoffman [mailto:paul(_dot_)hoffman(_at_)vpnc(_dot_)org] 
Sent: Wednesday, April 30, 2014 10:38 AM
To: Jim Schaad
Cc: smime(_at_)ietf(_dot_)org
Subject: Re: [smime] eContentType for detached signatures

On Apr 30, 2014, at 10:15 AM, Jim Schaad <ietf(_at_)augustcellars(_dot_)com> 

Oh God No.

Tell us what you really think, Jim. :-)

It has been my contention for a long time that the S/MIME group made a 
mistake by not defining a new content type for S/MIME messages which 
was id-ct-mime to allow for a processor to know that there was mime 
content inside rather than some unknown binary or text object (which 
happened to not be ASN.1).

That suggestion would be fine; it is also unrelated to the current topic. We
are talking about detached signatures on things that are not MIME-wrapped

[JLS] It shows that I have thought that the inner content type is not
restricted to being an identifier of an ASN.1 encoding object for so time.
I don't distinguish between having signatures on detached objects and having
signatures on embedded objects as they can be mechanically transformed
between each other.  Remember that S/MIME messages come in both forms -
embedded and detached.

What RFC 5485 did makes perfect sense to me and always has.  I 
completely disagree that there is any indication that the econtentType 
does not give an indication of what the inner content is, that is the 
complete purpose of the field.  The definition of eContentType is

eContentType is an object identifier.  The object identifier uniquely 
specifies the content type.

It does not say that this is how to know how to decode it - it says is 
uniquely specifies the content.  (And probably really should say 
content not content type.)  There is nothing here that says it needs 
to be an ASN.1 content for new OID values.

My proposal meets that definition. It specifies that the inner content type
is not specified.

[JLS] And with your proposal it does not say that you will have any idea of
either what the content is or how to decode it.  Note that with detached
content the fact that one may need to canonicalize the content before
hashing is a fact of life.  Please tell me that text files have the same
CRLF handing on all systems and this will go away.  If you cannot
distinguish between text and binary files (which may also contain CRLF and
LF sequences) then it becomes important.

One needs only to define a new content type for those things which 
need special handling before they are processed.  This is true for 
some contents defined in RFC 5485 (asciiTextWithCRLF and xml).

I'm not seeing what is the "special handling" needed for the detached
signatures defined in RF 5 485. That may be were we diverge so severely.

When you are validating a detached signature, what is the special handling

[JLS] Read sections 2.2 and 2.3 which both specify that there is
canonicalization that is to be performed on the detached content prior to
computing the hash.

It may be convenient to do
this for contents that are different and have no easy internal 
identification (this is true for the pdf and postscript types defined 
in RFC 5485).  For mime, one would need, at most, to define one which 
would be id-mime to say that mime is embedded.  If one wanted to 
directly include the content, without the mime wrapping, then yes, one 
could defined a new CMS content type for that purpose.  I think one 
would probably get pushback from the expert reviewers in this case (I 
know that I would) unless there appeared to be a good reason for dropping
the mime wrapping.

Again, this thread has nothing to do with MIME-wrapped content.

[JLS] This was a response to your comment in the message that  ". An
alternative would be to create OIDs for 
everything in the MIME registry, but this seems excessive and of little
value."  I was saying that this is not necessary for all cases but might be
needed if special processing is required.


--Paul Hoffman=

smime mailing list