From dominik@dominikschuermann.de Sat Oct 12 10:17:28 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0421E81AC for ; Sat, 12 Oct 2013 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbElKsmQFfpP for ; Sat, 12 Oct 2013 10:17:24 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0100421E81A9 for ; Sat, 12 Oct 2013 10:17:20 -0700 (PDT) Received: from [134.169.34.1] (helo=[10.1.0.103]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VV2oY-0007ew-W2 for dtn-security@irtf.org; Sat, 12 Oct 2013 19:17:19 +0200 Message-ID: <5259841B.5060109@dominikschuermann.de> Date: Sat, 12 Oct 2013 19:17:15 +0200 From: =?UTF-8?B?RG9taW5payBTY2jDvHJtYW5u?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: dtn-security X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4779D930333919080A41A12" X-Df-Sender: ZG9taW5pa0Bkb21pbmlrc2NodWVybWFubi5kZQ== Subject: [dtn-security] Mutable Canonicalization: including security-result length? X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 17:17:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4779D930333919080A41A12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding Mutable Canonicalization (http://tools.ietf.org/html/rfc6257#section-3.4.2). While Strict Canonicalization explicitly says that security-result is not part of the canonical form, but its length, I am unsure how this should be handled in Mutable Canonicalization. RFC says: "Security blocks are handled likewise, except that the ciphersuite will likely specify that the "current" security block security-result field not be considered part of the canonical form. This differs from the strict canonicalization case since we might use the mutable canonicalization algorithm to handle sequential signatures such that signatures cover earlier ones." Does this mean the length of security-result is not part of Mutable Canonicalization or do I miss something? Regards Dominik Sch=C3=BCrmann --------------enigC4779D930333919080A41A12 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSWYQeAAoJEHGMBwEAASKC4eUIAJbwD0gxCy9yJKgOHltyZPvb pGSx3Q3FJbS716lAXYaYZSoATxsd8zUE2g8yXnKlPGj5VFI+BKtlSNROumj6oBVm qwjEt0YFd/b3BbPCaf4UxuMM0WbckmCNc01tys+xPVrrRKMI6nwhTLiNp2bimjze 0z8FJojzTmA58pAdmDUjksM+CNlCBsxcZp4U7ID6ZI9Oj9PXY7WjSNPzQUbuBcHY xDYyyoK/IviL6jcrB2rYmQvt1DR85cKr+3IuWCSFFwqgtm6/cneIzc1aLGg43CcE lLwjmWskyJY/0G33q+i1rFB3cmCTj/QujYfPrRz2v8lBU3amtMCg6h1APJIuniQ= =JvnE -----END PGP SIGNATURE----- --------------enigC4779D930333919080A41A12-- From plovell@mac.com Sat Oct 12 20:27:29 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B34711E8158 for ; Sat, 12 Oct 2013 20:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTPh3zFJ068y for ; Sat, 12 Oct 2013 20:27:25 -0700 (PDT) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtp004.mac.com [17.172.81.3]) by ietfa.amsl.com (Postfix) with ESMTP id 2E73C21E80E7 for ; Sat, 12 Oct 2013 20:27:20 -0700 (PDT) Received: from [fe80::1] (pool-108-48-203-29.washdc.fios.verizon.net [108.48.203.29]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MUL00L1489H1P10@st11p00mm-asmtp004.mac.com> for dtn-security@irtf.org; Sun, 13 Oct 2013 03:27:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-10-12_01:2013-10-11, 2013-10-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1308280000 definitions=main-1310120177 From: Peter Lovell To: =?ISO-8859-1?Q?Dominik=20Sch=FCrmann?= , dtn-security Date: Sat, 12 Oct 2013 23:27:16 -0400 Message-id: <20131013032716.966655380@smtp.mail.me.com> In-reply-to: <5259841B.5060109@dominikschuermann.de> References: <5259841B.5060109@dominikschuermann.de> X-Mailer: CTM PowerMail version 6.2b1 build 4663 English (intel) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Subject: Re: [dtn-security] Mutable Canonicalization: including security-result length? X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 03:27:29 -0000 Hi Dominik, Section 3.4 (Canonicalization of Bundles) describes schemes for = canonicalization but unfortunately does not clarify the point that, although these are = used for the "standard" ciphersuites, other schemes can be used. To answer your very specific question, the paragraph that you reference is = part of the general description. The exact answer for the case of = PIB-RSA-SHA256 ciphersuite is contained in the description in section 4.2 ... >PIB-RSA-SHA256 uses the mutable canonicalization algorithm in Section = 3.4.2, with the >security-result data field for only the "current" block being excluded = from the >canonical form. So for this specific ciphersuite, the length is included in = canonicalization but the data field, quite obviously, is not. You may create your own ciphersuite with different rules for = canonicalization so long as you use use a different ID. Regards.....Peter Dominik Sch=FCrmann wrote: >Hi, > >I have a question regarding Mutable Canonicalization >(http://tools.ietf.org/html/rfc6257#section-3.4.2). > >While Strict Canonicalization explicitly says that security-result is >not part of the canonical form, but its length, I am unsure how this >should be handled in Mutable Canonicalization. > >RFC says: >"Security blocks are handled likewise, except that the ciphersuite > will likely specify that the "current" security block security-result > field not be considered part of the canonical form. This differs > from the strict canonicalization case since we might use the mutable > canonicalization algorithm to handle sequential signatures such that > signatures cover earlier ones." > >Does this mean the length of security-result is not part of Mutable >Canonicalization or do I miss something=3F > >Regards >Dominik Sch=FCrmann > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >dtn-security mailing list >dtn-security@irtf.org >https://www.irtf.org/mailman/listinfo/dtn-security From dominik@dominikschuermann.de Sun Oct 13 09:56:47 2013 Return-Path: X-Original-To: dtn-security@ietfa.amsl.com Delivered-To: dtn-security@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43BF11E81B0 for ; Sun, 13 Oct 2013 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.969 X-Spam-Level: X-Spam-Status: No, score=-0.969 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC+PedhfE5qD for ; Sun, 13 Oct 2013 09:56:42 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id CAC9311E81B1 for ; Sun, 13 Oct 2013 09:56:35 -0700 (PDT) Received: from [134.169.178.60] by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1VVOxy-0001Yj-NE; Sun, 13 Oct 2013 18:56:30 +0200 Message-ID: <525AD0BB.80705@dominikschuermann.de> Date: Sun, 13 Oct 2013 18:56:27 +0200 From: =?UTF-8?B?RG9taW5payBTY2jDvHJtYW5u?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Peter Lovell References: <5259841B.5060109@dominikschuermann.de> <20131013032716.966655380@smtp.mail.me.com> In-Reply-To: <20131013032716.966655380@smtp.mail.me.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC920067402CDE1D57A2C2433" X-Df-Sender: ZG9taW5pa0Bkb21pbmlrc2NodWVybWFubi5kZQ== Cc: dtn-security Subject: Re: [dtn-security] Mutable Canonicalization: including security-result length? X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:56:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC920067402CDE1D57A2C2433 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peter, thanks for your clarifications :) Regards Dominik On 13.10.2013 05:27, Peter Lovell wrote: > Hi Dominik, >=20 > Section 3.4 (Canonicalization of Bundles) describes schemes for canonic= alization but unfortunately does not clarify the point that, although the= se are used for the "standard" ciphersuites, other schemes can be used. >=20 > To answer your very specific question, the paragraph that you reference= is part of the general description. The exact answer for the case of PIB= -RSA-SHA256 ciphersuite is contained in the description in section 4.2 ..= =2E=20 >> PIB-RSA-SHA256 uses the mutable canonicalization algorithm in Section = 3.4.2, with the=20 >> security-result data field for only the "current" block being excluded= from the=20 >> canonical form. >=20 > So for this specific ciphersuite, the length is included in canonicaliz= ation but the data field, quite obviously, is not. >=20 > You may create your own ciphersuite with different rules for canonicali= zation so long as you use use a different ID.=20 >=20 > Regards.....Peter >=20 >=20 >=20 > Dominik Sch=C3=BCrmann wrote: >=20 >> Hi, >> >> I have a question regarding Mutable Canonicalization >> (http://tools.ietf.org/html/rfc6257#section-3.4.2). >> >> While Strict Canonicalization explicitly says that security-result is >> not part of the canonical form, but its length, I am unsure how this >> should be handled in Mutable Canonicalization. >> >> RFC says: >> "Security blocks are handled likewise, except that the ciphersuite >> will likely specify that the "current" security block security-resul= t >> field not be considered part of the canonical form. This differs >> from the strict canonicalization case since we might use the mutable= >> canonicalization algorithm to handle sequential signatures such that= >> signatures cover earlier ones." >> >> Does this mean the length of security-result is not part of Mutable >> Canonicalization or do I miss something? >> >> Regards >> Dominik Sch=C3=BCrmann >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >=20 >=20 --------------enigC920067402CDE1D57A2C2433 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJSWtC+AAoJEHGMBwEAASKCzSoH/2E7Iph947bWEF1hxr7LBCHF MUxnlA0jmSf1hR3u0yNUiJA6Dcfbk+Y7eky2Dfni0sNvGjW1DpVnYuTFZgvHwOrM MBw2OLqdHtL80SiCN6y5ItF6EGjmljQbZQWB7qDKjMHpUq+5ybYdtpLikDGAAjPn zrfKE0c95Gv6zQ9NImPeFdLnpNMtXwx0cQZrYJFAVXLKrpZYXMHMtKFfCq4XVXL3 Sh+5U6JI6eoks04Ru/E8aR76diBU11h7EeDn9MPrJD2q1zjnx6DVBm8P1Q8krepi i++yj0kah2eCTAcySR6sogDbDYDmoXU01LCB6BNyxgFzYkhz34rjDIhZMg5EgVY= =qMhS -----END PGP SIGNATURE----- --------------enigC920067402CDE1D57A2C2433--