Re: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01

Tony Cheneau <tony.cheneau@it-sudparis.eu> Mon, 24 May 2010 13:30 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 2F77D3A6BC3 for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 06:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.224
X-Spam-Level:
X-Spam-Status: No, score=-0.224 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, HELO_EQ_FR=0.35]
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 bjRikrQ+yrPU for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 06:30:20 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 34ED43A6BD1 for <cga-ext@ietf.org>; Mon, 24 May 2010 06:30:20 -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 72A92FE05AB; Mon, 24 May 2010 15:30:12 +0200 (CEST)
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 AFCAC404FA8; Mon, 24 May 2010 15:30:08 +0200 (CEST)
Received: from alf94-6-82-226-232-167.fbx.proxad.net (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (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 A6D522C181BB; Mon, 24 May 2010 15:30:08 +0200 (CEST)
Date: Mon, 24 May 2010 15:30:11 +0200
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@localhost.localdomain
To: "Laganier, Julien" <julienl@qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F00A75BD5@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.1005241451030.31700@localhost.localdomain>
References: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com> <BF345F63074F8040B58C00A186FCA57F1F00A75BD5@NALASEXMB04.na.qualcomm.com>
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: AFCAC404FA8.A9563
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.805, requis 6.01, BAYES_00 -2.60, 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-From: tony.cheneau@it-sudparis.eu
Cc: "CGA-EXT@ietf.org" <CGA-EXT@ietf.org>, "draft-cheneau-csi-send-sig-agility@tools.ietf.org" <draft-cheneau-csi-send-sig-agility@tools.ietf.org>
Subject: Re: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01
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: Mon, 24 May 2010 13:30:21 -0000

Hello Julien,


On Fri, 21 May 2010, Laganier, Julien wrote:

[...]
> FWIW - a strawman that seems to fulfill simpler requirements would be:
>
> - define NewSignature and NewCGA options that include the algorithm in use and are used in place of CGA and RSA Signature options when the algorithm in use is not RSA.
I would need several clarifications on this sentence:
- I do not see why we should define a NewCGA option. RFC 3971 defines a
   CGA Option that carries a CGA PDS (defined in RFC 3972) that is
   agnostic of the Public Key type. As long as the Public Key can be
   formatted as a DER-encoded ASN.1 structure of type
   SubjectPublicKeyInfo, this is not a problem. Did I miss something ? 
- concerning the NewSignature, do you think we should define a new one
   per Signature Algorithm ? So there will be one for RSA (already
   exists), one for ECDSA, as long as there is free value on the "IPv6
   Neighbor Discovery Option Formats" registry. Or do you think there is
   actually some value in our solution that defines an "Universal"
   Signature option that indicates the type of Digital Signature it
   carries.
   Since there is already a reserved field in the RSA Signature Option, I
   would not see why we could not use this field to do just that. Legacy
   nodes will try to process the option and fail when it is not RSA.
   Signature Agility enabled nodes will just do fine. What is you opinion
   on this ?


>
> - NewSignature and NewCGA options will be ignored by legacy nodes (i.e., conforming to RFC 3971) and thus messages carrying them will be treated as unsecured by these nodes.
>
> - specify NewSignature and NewCGA receiver processing such that a node that doesn't support said algorithm treats the message as unsecured.

Thanks (again) for your comments.

Regards,
 	Tony