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

Tony Cheneau <tony.cheneau@it-sudparis.eu> Sun, 21 March 2010 17:04 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9283A69F5 for <cga-ext@core3.amsl.com>; Sun, 21 Mar 2010 10:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.781
X-Spam-Level: *
X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+g3DuvOt0S7 for <cga-ext@core3.amsl.com>; Sun, 21 Mar 2010 10:04:13 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id C7DBE3A69CF for <cga-ext@ietf.org>; Sun, 21 Mar 2010 10:04:10 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id AB1C8FE4601; Sun, 21 Mar 2010 18:04:25 +0100 (CET)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id E81B4404FB4; Sun, 21 Mar 2010 18:04:20 +0100 (CET)
Received: from [10.59.24.225] (rrcs-64-183-74-195.west.biz.rr.com [64.183.74.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id A39A2900AF; Sun, 21 Mar 2010 18:04:19 +0100 (CET)
Date: Sun, 21 Mar 2010 18:04:16 +0100 (CET)
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
In-Reply-To: <B5ECF87DE53349CA9E810F121A0849B7@bombo>
Message-ID: <alpine.LNX.2.00.1003211739530.5453@whitebox>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox><BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com><alpine.LNX.2.00.0911201144010.7546@whitebox><BF345F63074F8040B58C00A186FCA57F1C65FB277D@NALASEXMB04.na.qualcomm.com><alpine.LNX.2.00.0911211025090.11248@localhost.localdomain><BF345F63074F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm.com><alpine.LNX.2.00.0911242317130.11124@localhost.localdomain><BF345F63074F8040B58C00A186FCA57F1C65FB2A51@NALASEXMB04.na.qualcomm.com><alpine.LNX.2.00.0911260951580.7596@whitebox><37915D90-B246-48E4-9C7B-69DAF54FA43A@lacnic.net><4B210E23.4000908@piuha.net><alpine.LNX.2.00.0912102300220.11124@localhost.localdomain> <4B21DA81.30405@piuha.net> <B5ECF87DE53349CA9E810F121A0849B7@bombo>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-9456351-1269191062=:5453"
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: E81B4404FB4.ACAE4
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-2.499, requis 6.01, BAYES_00 -2.60, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: draft-ietf-csi-proxy-send@tools.ietf.org, cga-ext@ietf.org
Subject: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Mar 2010 17:04:14 -0000

Hello Alberto,

I agree with your new text.

However, I can not help but think that the PadLen field will be
requiered later on, when other signature algorithms will be used (where
the signature may not encode its own lenght). 
I think the WG should have a discussion on re-introducing or justifying
the lack of PadLen field. Because, if you choose not to introduce it in
this spec, there might be two specs to fix later on.

Also, I spotted a small typo in the Reserved field:
"A 11-bit field reserved" => "A 16-bit field reserved"

Regards,
 	Tony

On Thu, 4 Mar 2010, Alberto García wrote:

> Hi
>
> |  -----Mensaje original-----
> |  De: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] En nombre
> de
> |  Jari Arkko
> |  Enviado el: viernes, 11 de diciembre de 2009 6:37
> |  Para: Tony Cheneau
> |  CC: draft-ietf-csi-proxy-send@tools.ietf.org; cga-ext@ietf.org
> |  Asunto: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
> |
> |  Tony,
> |
> |  > 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.
> |
> |  Ah, OK.
> |
> |  > 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 ?
> |
> |  I can't recall. Maybe this is one of the bugs that we need to fix. Or
> |  perhaps there is a way to determine the lengths but neither of us can't
> |  just see it right now. In any case, it should be clearly specified in
> |  3971bis and the proxy-send drafts.
>
> The length of the Digital Signature can be obtained from parsing the PKCS#1
> v1.5 signature itself, which is coded in ASN.1 BER.
> Therefore, I have changed in draft-ietf-csi-proxy-send-02 the statement
> saying:
>
> "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.)
>
> by
> "The length of the Digital Signature field is determined by the ASN.1 BER
> coding of the PKCS#1 v1.5 signature."
>
> Then, I would still say that
> "The length of the padding field is determined by the length of the Proxy
> Signature Option minus the length of the other fields."
>
> Do you think this is correct?
>
> Regards,
> Alberto
>
> |
> |  Jari
> |
> |  _______________________________________________
> |  CGA-EXT mailing list
> |  CGA-EXT@ietf.org
> |  https://www.ietf.org/mailman/listinfo/cga-ext
>
>