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

Peter Lovell <> Sun, 13 October 2013 03:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B34711E8158 for <>; Sat, 12 Oct 2013 20:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.903
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qTPh3zFJ068y for <>; Sat, 12 Oct 2013 20:27:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E73C21E80E7 for <>; Sat, 12 Oct 2013 20:27:20 -0700 (PDT)
Received: from [fe80::1] ( []) by (Oracle Communications Messaging Server 7u4-27.08( 64bit (built Aug 22 2013)) with ESMTPSA id <> for; 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: <>
In-reply-to: <>
References: <>
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-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. 


Dominik Schürmann <> wrote:

>I have a question regarding Mutable Canonicalization
>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?
>Dominik Schürmann
>dtn-security mailing list