Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send

Tony Cheneau <> Thu, 10 December 2009 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE8C83A68BB for <>; Thu, 10 Dec 2009 14:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TMO5UwTJVDx5 for <>; Thu, 10 Dec 2009 14:37:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EC8A43A6808 for <>; Thu, 10 Dec 2009 14:37:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 75B58FE0A7B; Thu, 10 Dec 2009 23:37:25 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id A3267404FAE; Thu, 10 Dec 2009 23:37:21 +0100 (CET)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 8225A9000D; Thu, 10 Dec 2009 23:37:21 +0100 (CET)
Date: Thu, 10 Dec 2009 23:37:15 +0100 (CET)
From: Tony Cheneau <>
X-X-Sender: shad@localhost.localdomain
To: Jari Arkko <>
In-Reply-To: <>
Message-ID: <alpine.LNX.2.00.0912102300220.11124@localhost.localdomain>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <> <alpine.LNX.2.00.0911201144010.7546@whitebox> <> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <> <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain> <> <alpine.LNX.2.00.0911260951580.7596@whitebox> <> <>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: A3267404FAE.A6D0B
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=2.294, requis 6.01, BAYES_05 -1.11, FH_HELO_EQ_D_D_D_D 0.00, HELO_DYNAMIC_IPADDR 2.43, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-SpamScore: ss
Subject: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2009 22:37:38 -0000

Hello Jari,

I'm not author of this document, but I implemented a bit of the SEND
protocol, so I think I can answer this one:

>>        This field starts after the Key Hash field.  The length of the
>>        Digital Signature field is determined by the length of the RSA
>>        Signature option minus the length of the other fields (including
>>        the variable length Pad field.)
>>     Padding
>>        This variable-length field contains padding, as many bytes long as
>>        remain after the end of the signature.
> I don't understand how to calculate the length of the Signature field, 
> because the padding field's length is not described anywhere.

The padding field is exactly defined this way in RFC 3971 (although a
Pad Length field was present on the -04 version of the SEND draft). 
I think the draft-ietf-csi-proxy-send-01 document only reuses the format
of the badly defined RSA Signature Option.

In the RSA signature option, you can check with the Key Hash field which
Public Key is linked to the Digital Signature field (it is often carried
by the CGA Option).  Then, the Public Key length determines the size of
the Digital Signature (1024 bits long key = 128 octets long Digital
Signature). Hence, you have a way to determine the size of the padding.

If you use a different Signature Algorithm with a varying Digital
Signature size, you still can choose to encode it in a DER-like format
(but this is mostly an hack...).

If RFC 3971 was to be updated, I agree that a padding length field should 
be defined somewhere in the RSA (or XXX) Signature Option. 
Was there a rational behind its removal during the RFC 3971
standardisation process ?