From nobody Thu May 1 11:38:11 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 7DAE31A6F8C for ; Thu, 1 May 2014 11:38:10 -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 pGaGeFOXz7Aa for ; Thu, 1 May 2014 11:38:09 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 267241A08B3 for ; Thu, 1 May 2014 11:38:09 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 14B06F2C08E; Thu, 1 May 2014 14:37:56 -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 DrOfrSkVyEyO; Thu, 1 May 2014 14:37:35 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 34374F2C08A; Thu, 1 May 2014 14:37:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> Date: Thu, 1 May 2014 14:37:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/vCNZjGPiWa1ANhrsz26EV8r-vRA Cc: IETF SMIME 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: Thu, 01 May 2014 18:38:10 -0000 Paul: I still think that we did a reasonable thing in RFC 5485. When I was looking at draft-flanagan-nonascii-01, it jumped out to me = that id-ct-asciiTextWithCRLF would not be appropriate for such = documents. I suggested that Heather add an appendix to assign an object = identifier for the UTF-8 documents that are described here. That is a = reasonable and consistent way forward. There is no place to carry a = media type in the detached signature. I think id-ct-mime is appropriate for a content that is MIME encoded. = That is, the media type is carried in the content. Russ On Apr 30, 2014, at 7:25 PM, Paul Hoffman wrote: > 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. >=20 > 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). >=20 > 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. >=20 > --Paul Hoffman From nobody Thu May 1 14:46:26 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 8F7E81A081F for ; Thu, 1 May 2014 14:46:24 -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 T8pWiOjQviCS for ; Thu, 1 May 2014 14:46:23 -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 916951A063B for ; Thu, 1 May 2014 14:46:23 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s41LkIGf064650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 May 2014 14:46:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] 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: Date: Thu, 1 May 2014 14:46:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <678A17A5-64D3-4CB9-B92C-966FF561D7F1@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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> To: Russ Housley X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/JAdduo0uOZ2Vm6-s2q0UfeyWX8U Cc: IETF SMIME 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: Thu, 01 May 2014 21:46:24 -0000 On May 1, 2014, at 11:37 AM, Russ Housley wrote: > I still think that we did a reasonable thing in RFC 5485. In retrospect, the general idea of "here's a marker for what needs to be = canonicalized for signing (but not storage) and validating" is probably = a good one. The implementation on RFC 5485 is confusing and possibly = over-broad. > When I was looking at draft-flanagan-nonascii-01, it jumped out to me = that id-ct-asciiTextWithCRLF would not be appropriate for such = documents. I suggested that Heather add an appendix to assign an object = identifier for the UTF-8 documents that are described here. That is a = reasonable and consistent way forward. There is no place to carry a = media type in the detached signature. >=20 > I think id-ct-mime is appropriate for a content that is MIME encoded. = That is, the media type is carried in the content. Jim and I discussed this a bit offline and came up with a reasonable way = forward. - Obsolete RFC 5485 with a new document of similar structure but more = careful wording. - Create a new CMS content type id-ct-canonicalizedText that is defined = to solve the problems of line-ending changes that happen in FTP and in = some browsers when saving files to disk as text *and that is all*. It = would cover any text encoded in UTF-8. Do not include stripping of white = space before line ends; if you do, fully define what characters are = "white space" Make it very clear that this canonicalization is only for = the signing and validation steps, *not* for storage on disk or = conversion between attached and detached signatures. - Create a new CMS content type id-ct-mime to assist processors that = need to know the inner content type of non-text items. - Discuss that non-text content should be marked with id-data. - Deprecate all the id-ct values in RFC 5485. This will have nearly zero = operational impact because the signatures are not long-term (and in fact = are not being created today due to software bugs). --Paul Hoffman= From nobody Fri May 2 03:40:38 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 E77D41A6F06 for ; Fri, 2 May 2014 03:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.598 X-Spam-Level: *** X-Spam-Status: No, score=3.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 aLf5EwDEkJiA for ; Fri, 2 May 2014 03:40:34 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3131A6EFB for ; Fri, 2 May 2014 03:40:34 -0700 (PDT) Message-Id: <201405021040.s42AeUxq068261@mail.nbusr.sk> From: "Peter Rybar" To: "'Paul Hoffman'" , "'Russ Housley'" Date: Fri, 2 May 2014 12:40:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> Thread-Index: Ac9lhs5oYQ2xYpnwQGODU3msTTXmkwAYO5XA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: * X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 1.5 X-NAI-Spam-Version: 2.3.0.9378 : core <4929> : inlines <804> : streams <1171061> : uri <1746495> Archived-At: http://mailarchive.ietf.org/arch/msg/smime/omnnLrQ2ekMbJCQ-6m7kthociik Cc: 'Peter Rybar' , 'IETF SMIME' 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: Fri, 02 May 2014 10:40:37 -0000 Dear all, When the binary data (included in a file) are not the same as the HASED = binary data (included in a hashing procedure), because before hashing = procedure the data are transformed into the canonical form, there must = be also defined a new OID for a new canonicalMessageDigest because for = OBJECT IDENTIFIER 1.2.840.113549.1.9.4 messageDigest are defined rules = where the whole data are as input to the hashing procedure. The solution, when the whole binary data are hashed but the type of the = data interpretation/processing is important, for the protection of the = type of signed data is used signed attribute id-aa-contentHint [RFC2634] = where contentDescription field contains MIME header with MIME = Content-Type: SEQUENCE { OBJECT IDENTIFIER 1.2.840.113549.1.9.16.2.4 contentHint SET { ContentHints SEQUENCE { contentDescription UTF8String=20 MIME-Version: 1.0 Content-Type: application/vnd.oasis.opendocument.text; = name=3D"ATT00122.odt" Content-Disposition: attachment; filename=3D"ATT00122.odt" contentType OBJECT IDENTIFIER 1.2.840.113549.1.7.1 data } } } It is also used for secure publication of web files with external CMS = signature e.g. for a trusted list protection = http://www.nbusr.sk/en/electronic-signature/signature-policies.1.html=20 http://ep.nbusr.sk/kca/tsl/tsl.xml.p7s=20 When some new rules are expected e.g. when id-ct-canonicalizedText will = be defined then also id-aa-canonicalMessageDigest must be defined and = used. Proposed creation of a new CMS content type id-ct-mime can be more = helpful when the document(s) will be signed indirectly. Signed document identified by id-ct-mime will be DER or maybe a JSON = encoded DataReferences type. When charset is UTF-8 then it is a binary = file without canonicalization. Only ASCII txt can be processed with = canonicalization. The JSON proposal below, containing ASCII and UTF-8 data, can be also = transformed as ASN.1: DataReferences: { "hash": { "OID": "2.16.840.1.101.3.4.2.1", "parameters": "", "name": "SHA256" },=20 "fields": [=20 { "data": { "url": "http://www.archive.eu/docs/?typ=3D123", "name": "invoice", "ext": "txt", "Content-Type": "text/plain" =20 }, "canonicalization": { "OID": "1.2.840.113549.1.7.27", "name": "asciiTextWithCRLF" }, =20 "hash": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=3D", "info": "invoice 123" }, { "data": { "url": "http://www.archive.eu/docs/?typ=3D432", "name": "invoice", "ext": "txt", "Content-Type": "text/plain; charset=3DUTF-8" }, "hash": "JspKEHtF3LyCalml/2mXuG1jLZ2NjdQCo2hkn+49k7o=3D", "info": "invoice 432" } ] }=20 =20 Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic tel.: +421 2 6869 2163 mob.: +421 903 993 708 fax: +421 2 6869 1701 e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Thursday, May 01, 2014 11:46 PM To: Russ Housley Cc: IETF SMIME Subject: Re: [smime] eContentType for detached signatures On May 1, 2014, at 11:37 AM, Russ Housley wrote: > I still think that we did a reasonable thing in RFC 5485. In retrospect, the general idea of "here's a marker for what needs to be = canonicalized for signing (but not storage) and validating" is probably = a good one. The implementation on RFC 5485 is confusing and possibly = over-broad. > When I was looking at draft-flanagan-nonascii-01, it jumped out to me = that id-ct-asciiTextWithCRLF would not be appropriate for such = documents. I suggested that Heather add an appendix to assign an object = identifier for the UTF-8 documents that are described here. That is a = reasonable and consistent way forward. There is no place to carry a = media type in the detached signature. >=20 > I think id-ct-mime is appropriate for a content that is MIME encoded. = That is, the media type is carried in the content. Jim and I discussed this a bit offline and came up with a reasonable way = forward. - Obsolete RFC 5485 with a new document of similar structure but more = careful wording. - Create a new CMS content type id-ct-canonicalizedText that is defined = to solve the problems of line-ending changes that happen in FTP and in = some browsers when saving files to disk as text *and that is all*. It = would cover any text encoded in UTF-8. Do not include stripping of white = space before line ends; if you do, fully define what characters are = "white space" Make it very clear that this canonicalization is only for = the signing and validation steps, *not* for storage on disk or = conversion between attached and detached signatures. - Create a new CMS content type id-ct-mime to assist processors that = need to know the inner content type of non-text items. - Discuss that non-text content should be marked with id-data. - Deprecate all the id-ct values in RFC 5485. This will have nearly zero = operational impact because the signatures are not long-term (and in fact = are not being created today due to software bugs). --Paul Hoffman _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime From nobody Fri May 2 07:23:30 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 9220B1A6FE0 for ; Fri, 2 May 2014 07:23:27 -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 6YuK1a2rtccA for ; Fri, 2 May 2014 07:23:26 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id CF6CA1A6FBC for ; Fri, 2 May 2014 07:23:25 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 459ECF2C08A; Fri, 2 May 2014 10:23:13 -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 0GIJVUqayASU; Fri, 2 May 2014 10:22:52 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 568A3F2C088; Fri, 2 May 2014 10:22:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> Date: Fri, 2 May 2014 10:22:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> 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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/X6IKQGc9IGRhi5lzWxDX-Wjc7PI Cc: IETF SMIME 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: Fri, 02 May 2014 14:23:27 -0000 Paul: I do not agree. When working on RFC 5485, the idea was to use a = canonicalization that was already well defined and widely implemented. = That is why the FTP wire format for plain text was selected. The detached signature should, in my opinion tell the type of the = content being signed. The use of id-data does not convey this = information. Your last point is incorrect. There have been many I-D signatures that = are correct using id-ct-asciiTextWithCRLF. There are software bugs, and = they are being worked, but some of the signatures are valid. I have no problem with defining id-ct-mime for cases where the content = is MIME encoded. This object identifier would essentially mean, parse = the content to extract the media type. Russ On May 1, 2014, at 5:46 PM, Paul Hoffman wrote: > On May 1, 2014, at 11:37 AM, Russ Housley = wrote: >=20 >> I still think that we did a reasonable thing in RFC 5485. >=20 > In retrospect, the general idea of "here's a marker for what needs to = be canonicalized for signing (but not storage) and validating" is = probably a good one. The implementation on RFC 5485 is confusing and = possibly over-broad. >=20 >> When I was looking at draft-flanagan-nonascii-01, it jumped out to me = that id-ct-asciiTextWithCRLF would not be appropriate for such = documents. I suggested that Heather add an appendix to assign an object = identifier for the UTF-8 documents that are described here. That is a = reasonable and consistent way forward. There is no place to carry a = media type in the detached signature. >>=20 >> I think id-ct-mime is appropriate for a content that is MIME encoded. = That is, the media type is carried in the content. >=20 > Jim and I discussed this a bit offline and came up with a reasonable = way forward. >=20 > - Obsolete RFC 5485 with a new document of similar structure but more = careful wording. >=20 > - Create a new CMS content type id-ct-canonicalizedText that is = defined to solve the problems of line-ending changes that happen in FTP = and in some browsers when saving files to disk as text *and that is = all*. It would cover any text encoded in UTF-8. Do not include stripping = of white space before line ends; if you do, fully define what characters = are "white space" Make it very clear that this canonicalization is only = for the signing and validation steps, *not* for storage on disk or = conversion between attached and detached signatures. >=20 > - Create a new CMS content type id-ct-mime to assist processors that = need to know the inner content type of non-text items. >=20 > - Discuss that non-text content should be marked with id-data. >=20 > - Deprecate all the id-ct values in RFC 5485. This will have nearly = zero operational impact because the signatures are not long-term (and in = fact are not being created today due to software bugs). >=20 > --Paul Hoffman From nobody Fri May 2 07:52:42 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 E5F621A7011 for ; Fri, 2 May 2014 07:52:40 -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 u6FF0tcVWtG2 for ; Fri, 2 May 2014 07:52:40 -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 357A81A6FF4 for ; Fri, 2 May 2014 07:52:40 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s42EqZca090545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 May 2014 07:52:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] 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: <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> Date: Fri, 2 May 2014 07:52:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <138A3C28-D2D8-43B2-AAC4-4FED0E297DDA@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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/p3R1gb8ru-qMsy8Ab2T8CK_Z19Y Cc: IETF SMIME 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: Fri, 02 May 2014 14:52:41 -0000 On May 2, 2014, at 7:22 AM, Russ Housley wrote: > I do not agree. When working on RFC 5485, the idea was to use a = canonicalization that was already well defined and widely implemented. =20= NVT-ASCII is well defined and is not widely implemented, at least not = implemented correctly. > That is why the FTP wire format for plain text was selected. Calling NVT-ASCII the "FTP wire format" is an overstatement. Many or = most implementations only do the CRLF transposition, not the whitespace = stripping. > The detached signature should, in my opinion tell the type of the = content being signed. The use of id-data does not convey this = information. This means that anyone who wants to create a detached signature for a = type of data that is not currently in the registry needs to write a = specification and apply for one. It seems strange to believe that no one = in the past five years has created a detached signature for, say, an = MP3, a stand-alone HTML file or a JSON file. > Your last point is incorrect. There have been many I-D signatures = that are correct using id-ct-asciiTextWithCRLF. There are software = bugs, and they are being worked, but some of the signatures are valid. Are you saying there will be significant negative operational impact of = replacing those signatures with new ones? Given the "some" in that last = sentence, I'm not sure I can imagine the problems. > I have no problem with defining id-ct-mime for cases where the content = is MIME encoded. This object identifier would essentially mean, parse = the content to extract the media type. That was the least important proposal of the bunch for the work at hand. --Paul Hoffman= From nobody Fri May 2 08:01:56 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 AD1AD1A08DE for ; Fri, 2 May 2014 08:01:55 -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 V5zHM268yQA3 for ; Fri, 2 May 2014 08:01:50 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 617011A08DA for ; Fri, 2 May 2014 08:01:50 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7DD10F2C09C; Fri, 2 May 2014 11:01:38 -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 BXcH382qR5fq; Fri, 2 May 2014 11:01:17 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D10CAF2C08E; Fri, 2 May 2014 11:01:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <138A3C28-D2D8-43B2-AAC4-4FED0E297DDA@vpnc.org> Date: Fri, 2 May 2014 11:01:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <00D72601-4B3F-4CF2-AF0E-E7DA02FAB820@vigilsec.com> 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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> <138A3C28-D2D8-43B2-AAC4-4FED0E297DDA@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/YQdNq9FUbwSI4G4jRi11nqcJmzw Cc: IETF SMIME 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: Fri, 02 May 2014 15:01:55 -0000 Paul: >> Your last point is incorrect. There have been many I-D signatures = that are correct using id-ct-asciiTextWithCRLF. There are software = bugs, and they are being worked, but some of the signatures are valid. >=20 > Are you saying there will be significant negative operational impact = of replacing those signatures with new ones? Given the "some" in that = last sentence, I'm not sure I can imagine the problems. New signatures need to be generated for the I-D where there was a = canonicalization problem. The ones that did not have a canonicalization = problem do not need new signatures. Russ From nobody Fri May 2 08:11:43 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 71AA71A6FD6 for ; Fri, 2 May 2014 08:11:41 -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 9a7fxwl1WRAi for ; Fri, 2 May 2014 08:11:34 -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 61E741A0A0D for ; Fri, 2 May 2014 08:11:34 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s42FBUTW091060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 May 2014 08:11:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-25.dsl.dynamic.sonic.net [50.1.98.25] 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: <00D72601-4B3F-4CF2-AF0E-E7DA02FAB820@vigilsec.com> Date: Fri, 2 May 2014 08:11:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> <138A3C28-D2D8-43B2-AAC4-4FED0E297DDA@vpnc.org> <00D72601-4B3F-4CF2-AF0E-E7DA02FAB820@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/XpzT6TnSy5GxdIrJj5f1TmWcTHQ Cc: IETF SMIME 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: Fri, 02 May 2014 15:11:41 -0000 On May 2, 2014, at 8:01 AM, Russ Housley wrote: > Paul: >=20 >>> Your last point is incorrect. There have been many I-D signatures = that are correct using id-ct-asciiTextWithCRLF. There are software = bugs, and they are being worked, but some of the signatures are valid. >>=20 >> Are you saying there will be significant negative operational impact = of replacing those signatures with new ones? Given the "some" in that = last sentence, I'm not sure I can imagine the problems. >=20 > New signatures need to be generated for the I-D where there was a = canonicalization problem. The ones that did not have a canonicalization = problem do not need new signatures. Quite true. We could have two different content types on the signatures, = the old and the new. That seems silly, though, if no one is relying on = the old signatures. --Paul Hoffman= From nobody Fri May 2 08:52: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 364821A6F6B for ; Fri, 2 May 2014 08:52:34 -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 kGWh-hdX19KA for ; Fri, 2 May 2014 08:52:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC711A6F24 for ; Fri, 2 May 2014 08:52:32 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 95549F2C08E; Fri, 2 May 2014 11:52:20 -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 nROW6DHgIuW1; Fri, 2 May 2014 11:51:59 -0400 (EDT) Received: from [192.168.2.100] (pool-96-241-160-129.washdc.fios.verizon.net [96.241.160.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BFCC4F2C088; Fri, 2 May 2014 11:51:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Fri, 2 May 2014 11:51:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F6A65D3-FD26-4152-AE65-577CD94F4C83@vigilsec.com> 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> <60769A97-1468-458A-BA7A-F90DBE554177@vpnc.org> <678A17A5-64D3-4CB9-B92C-966FF561D7F1@vpnc.org> <8A4FF9BA-7EEC-472A-9B0A-8C9668AF4D9A@vigilsec.com> <138A3C28-D2D8-43B2-AAC4-4FED0E297DDA@vpnc.org> <00D72601-4B3F-4CF2-AF0E-E7DA02FAB820@vigilsec.com> To: Paul Hoffman X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/smime/5Hafjc-6z-z61A1m19vh2aBAO6Q Cc: IETF SMIME 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: Fri, 02 May 2014 15:52:34 -0000 Paul: >>>> Your last point is incorrect. There have been many I-D signatures = that are correct using id-ct-asciiTextWithCRLF. There are software = bugs, and they are being worked, but some of the signatures are valid. >>>=20 >>> Are you saying there will be significant negative operational impact = of replacing those signatures with new ones? Given the "some" in that = last sentence, I'm not sure I can imagine the problems. >>=20 >> New signatures need to be generated for the I-D where there was a = canonicalization problem. The ones that did not have a canonicalization = problem do not need new signatures. >=20 > Quite true. We could have two different content types on the = signatures, the old and the new. That seems silly, though, if no one is = relying on the old signatures. What? We cannot know that yet. =46rom RFC 5485: ... At this point in time, it is important to support signature validation of expired Internet-Drafts that are obtained from non-IETF repositories. Therefore, the appropriate value for such a signed attribute is unclear. This specification allows an Internet-Draft and companion signature file to be stored anywhere without hindering signature validation. The point is that the files can be gathers from anywhere on the = Internet. Then, the digital signature will show that the file has not = been changed from the one posted by the IETF Secretariat. At some = point, I hope this signature validation will allow lawyers to perform = this check and stop asking the IETF to make such confirmations in = subpoenas. Russ