Re: [dtn-security] Mutable Canonicalization: including security-result length?

Dominik Schürmann <dominik@dominikschuermann.de> Sun, 13 October 2013 16:56 UTC

Return-Path: <dominik@dominikschuermann.de>
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 <dtn-security@ietfa.amsl.com>; 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 <dtn-security@ietfa.amsl.com>; 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 <dtn-security@irtf.org>; 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 <dominik@dominikschuermann.de>) 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?= <dominik@dominikschuermann.de>
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 <plovell@mac.com>
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 <dtn-security@irtf.org>
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." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2013 16:56:47 -0000

Hi Peter,

thanks for your clarifications :)

Regards
Dominik

On 13.10.2013 05:27, Peter Lovell wrote:
> 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ürmann <dominik@dominikschuermann.de> 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?
>>
>> Regards
>> Dominik Schürmann
>>
>> _______________________________________________
>> dtn-security mailing list
>> dtn-security@irtf.org
>> https://www.irtf.org/mailman/listinfo/dtn-security
> 
>