From nobody Thu Apr 24 09:08:59 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065441A035B for ; Thu, 24 Apr 2014 09:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrXeEC1lpkY5 for ; Thu, 24 Apr 2014 09:08:55 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC911A0318 for ; Thu, 24 Apr 2014 09:08:55 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id D0F5B9A43E5 for ; Thu, 24 Apr 2014 12:08:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id BA+nlLVQAwO3 for ; Thu, 24 Apr 2014 12:08:15 -0400 (EDT) Received: from 156-193.netmundial.org (unknown [199.91.193.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 861669A43E7 for ; Thu, 24 Apr 2014 12:08:15 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Apr 2014 12:08:14 -0400 References: <20140424160525.2555.49086.idtracker@ietfa.amsl.com> To: IETF SMIME Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/E4y4W7q6nDNG8LtEWjAUcsDKfqc Subject: [smime] New Version Notification for draft-housley-cms-mts-hash-sig-01.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:08:57 -0000 > From: internet-drafts@ietf.org > Date: April 24, 2014 12:05:25 PM EDT > To: "Russ Housley" , Russ Housley = > Subject: New Version Notification for = draft-housley-cms-mts-hash-sig-01.txt >=20 >=20 > A new version of I-D, draft-housley-cms-mts-hash-sig-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-mts-hash-sig > Revision: 01 > Title: Use of the Hash-based Merkle Tree Signature = (MTS) Algorithm in the Cryptographic Message Syntax (CMS) > Document date: 2014-04-24 > Group: Individual Submission > Pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-housley-cms-mts-hash-sig-01.txt > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-mts-hash-sig/ > Htmlized: = http://tools.ietf.org/html/draft-housley-cms-mts-hash-sig-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-housley-cms-mts-hash-sig-01 >=20 > Abstract: > This document specifies the conventions for using the Merkle Tree > Signatures (MTS) digital signature algorithm with the Cryptographic > Message Syntax (CMS). The MTS algorithm is one form of hash-based > digital signature. From nobody Wed Apr 30 09:25:47 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEAD1A0903 for ; Wed, 30 Apr 2014 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-sI-W8VzXQh for ; Wed, 30 Apr 2014 09:25:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 46BCF1A08E8 for ; Wed, 30 Apr 2014 09:25:41 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3UGPcbM008371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 30 Apr 2014 09:25:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> Date: Wed, 30 Apr 2014 09:25:36 -0700 To: smime@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/IJyeM53oljxwqPAdSJlkD7SeRH0 Subject: [smime] eContentType for detached signatures X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 16:25:47 -0000 Greetings again. An issue has come forth that significantly affects = S/MIME, specifically detached signatures. It would be good if this group = (which hasn't been a WG in four years) could weigh in on the topic. RFC 5485 describes how to use S/MIME detached signatures to sign = Internet Drafts. That RFC was not produced by this group, and was barely = discussed here at all. (There was a two-day discussion under the subject = of "Please review draft-housley-internet-draft-sig-file-00.txt"). That = RFC makes a significant change to detached signatures in that it make = the eContentType define the type of document that is being signed, and = names four content types, none of which are formally defined. If you = look at the table labeled "SMI Security for S/MIME CMS Content Type = (1.2.840.113549.1.9.16.1)" in = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 26, you see that those four types are the only non-security types in the = table.=20 The rationale at the time for this design choice was approximately "a = detached signature over a file that has no MIME information needs to = specify the content type of the file". The files being signed in RFC = 5485 don't have any MIME information, so RFC 5485 created CMS content = types for them. Note that any file can have detached signatures, not just the four types = of files named in RFC 5485. RFC 3852, our standard, talks a bit about = detached signatures: The optional omission of the eContent within the EncapsulatedContentInfo field makes it possible to construct "external signatures." In the case of external signatures, the content being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present. Nothing there says to me that the eContentType should be usable by a = receiving party to know what the inner content type is. There was no = concept of that in any of the three versions of the CMS standard. To me, RFC 5485 took the wrong path. It should not be required that = every time someone wants to create a detached signature over a file, = they need to register a new CMS content type. Instead, there should be = one eContentType for detached signatures that is defined as "inner = content type is undefined". An alternative would be to create OIDs for = everything in the MIME registry, but this seems excessive and of little = value. Thoughts appreciated. --Paul Hoffman= From nobody Wed Apr 30 10:17:18 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A51A883E for ; Wed, 30 Apr 2014 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAom-1QOJWSU for ; Wed, 30 Apr 2014 10:17:16 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19FD81A7034 for ; Wed, 30 Apr 2014 10:17:16 -0700 (PDT) Received: from Philemon (c-76-28-228-233.hsd1.wa.comcast.net [76.28.228.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A8CB82CA2E; Wed, 30 Apr 2014 10:17:14 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , References: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> In-Reply-To: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> Date: Wed, 30 Apr 2014 10:15:16 -0700 Message-ID: <0c4f01cf6497$c1b7c800$45275800$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWLF/turK4xcxYtDdJcPIjh2pPg5qc0xZw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/smime/m0hS4ompMJZOeoFEZomB6zguZ8U Subject: Re: [smime] eContentType for detached signatures X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:17:18 -0000 Oh God No. 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). 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. 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). 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. Jim -----Original Message----- From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, April 30, 2014 9:26 AM To: smime@ietf.org Subject: [smime] eContentType for detached signatures Greetings again. An issue has come forth that significantly affects S/MIME, specifically detached signatures. It would be good if this group (which hasn't been a WG in four years) could weigh in on the topic. RFC 5485 describes how to use S/MIME detached signatures to sign Internet Drafts. That RFC was not produced by this group, and was barely discussed here at all. (There was a two-day discussion under the subject of "Please review draft-housley-internet-draft-sig-file-00.txt"). That RFC makes a significant change to detached signatures in that it make the eContentType define the type of document that is being signed, and names four content types, none of which are formally defined. If you look at the table labeled "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" in http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-26 , you see that those four types are the only non-security types in the table. The rationale at the time for this design choice was approximately "a detached signature over a file that has no MIME information needs to specify the content type of the file". The files being signed in RFC 5485 don't have any MIME information, so RFC 5485 created CMS content types for them. Note that any file can have detached signatures, not just the four types of files named in RFC 5485. RFC 3852, our standard, talks a bit about detached signatures: The optional omission of the eContent within the EncapsulatedContentInfo field makes it possible to construct "external signatures." In the case of external signatures, the content being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present. Nothing there says to me that the eContentType should be usable by a receiving party to know what the inner content type is. There was no concept of that in any of the three versions of the CMS standard. To me, RFC 5485 took the wrong path. It should not be required that every time someone wants to create a detached signature over a file, they need to register a new CMS content type. Instead, there should be one eContentType for detached signatures that is defined as "inner content type is undefined". An alternative would be to create OIDs for everything in the MIME registry, but this seems excessive and of little value. Thoughts appreciated. --Paul Hoffman _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime From nobody Wed Apr 30 10:39:28 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213BE1A0922 for ; Wed, 30 Apr 2014 10:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN0gmADt_sb1 for ; Wed, 30 Apr 2014 10:39:25 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 30EF61A0913 for ; Wed, 30 Apr 2014 10:39:25 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3UHc5Wi010623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 10:38:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <0c4f01cf6497$c1b7c800$45275800$@augustcellars.com> Date: Wed, 30 Apr 2014 10:38:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <54F22EB1-F5E8-4F52-B436-E3AB4FA6C4C9@vpnc.org> References: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> <0c4f01cf6497$c1b7c800$45275800$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/EBazCXqbxJwHrswgLlO3wFbtKIY Cc: smime@ietf.org Subject: Re: [smime] eContentType for detached signatures X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:39:26 -0000 On Apr 30, 2014, at 10:15 AM, Jim Schaad wrote: > 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).=20 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 objects. > 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 >=20 > eContentType is an object identifier. The object identifier uniquely > specifies the content type. >=20 > 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. > 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). =20 I'm not seeing what is the "special handling" needed for the detached = signatures defined in RF 5485. That may be were we diverge so severely. When you are validating a detached signature, what is the special = handling needed? > 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. --Paul Hoffman= From nobody Wed Apr 30 12:21:35 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4E1A886D for ; Wed, 30 Apr 2014 12:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbc2ZL7v9FtT for ; Wed, 30 Apr 2014 12:21:31 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6A1A886B for ; Wed, 30 Apr 2014 12:21:31 -0700 (PDT) Received: from Philemon (unknown [207.145.231.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E29B12C9EB; Wed, 30 Apr 2014 12:21:26 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" References: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> <0c4f01cf6497$c1b7c800$45275800$@augustcellars.com> <54F22EB1-F5E8-4F52-B436-E3AB4FA6C4C9@vpnc.org> In-Reply-To: <54F22EB1-F5E8-4F52-B436-E3AB4FA6C4C9@vpnc.org> Date: Wed, 30 Apr 2014 12:19:27 -0700 Message-ID: <0c6d01cf64a9$1c3a7f00$54af7d00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWLF/turK4xcxYtDdJcPIjh2pPgwFRHJPOApGLo2WafeIR8A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/smime/0XXY-BRQbGbkKaSv5MrOQcTK3Ow Cc: smime@ietf.org Subject: Re: [smime] eContentType for detached signatures X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:21:33 -0000 -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, April 30, 2014 10:38 AM To: Jim Schaad Cc: smime@ietf.org Subject: Re: [smime] eContentType for detached signatures On Apr 30, 2014, at 10:15 AM, Jim Schaad wrote: > 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 objects. [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 needed? [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. Jim --Paul Hoffman= From nobody Wed Apr 30 16:26:55 2014 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E09E1A6F28 for ; Wed, 30 Apr 2014 16:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5dZRLjcrmI7 for ; Wed, 30 Apr 2014 16:26:41 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8D35A1A09CD for ; Wed, 30 Apr 2014 16:26:41 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3UNPKOl021821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Apr 2014 16:25:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-198.dsl.dynamic.fusionbroadband.com [142.254.17.198] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <0c6d01cf64a9$1c3a7f00$54af7d00$@augustcellars.com> Date: Wed, 30 Apr 2014 16:25:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> References: <8FCFCAB8-4101-4F90-98E9-DDA458C0C2C5@vpnc.org> <0c4f01cf6497$c1b7c800$45275800$@augustcellars.com> <54F22EB1-F5E8-4F52-B436-E3AB4FA6C4C9@vpnc.org> <0c6d01cf64a9$1c3a7f00$54af7d00$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/NjXIoCe1KbNL0iwH6394KhR2DrY Cc: smime@ietf.org Subject: Re: [smime] eContentType for detached signatures X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 23:26:43 -0000 We agree that having a id-ct-mime would be a good thing. We also seem to = agree that id-ct-asciiTextWithCRLF signals that the content must be be = processed with the exact canonicalization specified in RFC 5485 before = signing and validation. I was wrong when I said that I didn't see the = need for the type for the content type you are focused on; I was = actually looking at the other two types that were defined in RFC 5485, = id-ct-xml and id-ct-pdf, which do not use the canonicalization rules = given in the RFC. It was from there that I worry that this indicates = that all types, not only those that need canonicalization, need to be = defined, given that we have no definition for any. This thread was prompted by Russ asking that, when Internet Drafts and = RFCs no longer are expected to be all-ASCII, do we need another CMS = content type. To me, this means making up a new canonicalization form = for these, but we will also need to make one up for all the for other = types that might be published. Further, it pointed out to me that the = canonicalization that is defined in RFC 5485 is already fragile. It = doesn't apply to two of the types defined in that RFC, and it makes a = false assumption that all inputs are really ASCII (sometimes, non-ASCII = characters slip through). So, I still question whether or not RFC 5485 did the right thing in = defining id-ct-xml and id-ct-pdf, and particularly in not defining = something that could be called id-ct-unknown. --Paul Hoffman=