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

"Laganier, Julien" <julienl@qualcomm.com> Mon, 24 May 2010 17:22 UTC

Return-Path: <julienl@qualcomm.com>
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 5BABA3A6848 for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 10:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.238
X-Spam-Level:
X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 pNRHvE+kemSl for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 10:22:40 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BCB743A6831 for <CGA-EXT@ietf.org>; Mon, 24 May 2010 10:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1274721752; x=1306257752; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Tony=20Cheneau=20<tony.cheneau@it-sudparis.eu>|CC: =20"CGA-EXT@ietf.org"=20<CGA-EXT@ietf.org>,=0D=0A=09"draf t-cheneau-csi-send-sig-agility@tools.ietf.org"=0D=0A=09<d raft-cheneau-csi-send-sig-agility@tools.ietf.org>|Date: =20Mon,=2024=20May=202010=2010:22:04=20-0700|Subject:=20R E:=20Review=20of=20draft-cheneau-csi-send-sig-agility-01 |Thread-Topic:=20Review=20of=20draft-cheneau-csi-send-sig -agility-01|Thread-Index:=20Acr7RT3vwXteOT4CT1y6c3j1+r/3u AAH3bSw|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F 00A75C52@NALASEXMB04.na.qualcomm.com>|References:=20<BF34 5F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qua lcomm.com>=0D=0A=20<BF345F63074F8040B58C00A186FCA57F1F00A 75BD5@NALASEXMB04.na.qualcomm.com>=0D=0A=20<alpine.LNX.2. 00.1005241451030.31700@localhost.localdomain> |In-Reply-To:=20<alpine.LNX.2.00.1005241451030.31700@loca lhost.localdomain>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=dJumEajQr2AqMt6b1TJQNJLE67O0nG83W5EOVLKH/sg=; b=fQWOMN28fvi6hMha/85RcDw4DO/ioGCkFOlbJPR+JZoSqu58ANO5rBRQ uWLFBFKt18qF90/pZMm+V7ntpHxnao0v63QQOiPJDkp2ml4VPA2tM4fxX lfZhkmGjOr+zcnrmoiDyN1YuQZRopJkkOc+FKrzI2OkuH0ZOgZgjhmyAQ c=;
X-IronPort-AV: E=McAfee;i="5400,1158,5992"; a="42261507"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 24 May 2010 10:22:29 -0700
X-IronPort-AV: E=Sophos;i="4.53,291,1272870000"; d="scan'208";a="65347282"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 May 2010 10:22:10 -0700
Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 24 May 2010 10:22:04 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Mon, 24 May 2010 10:22:03 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Tony Cheneau <tony.cheneau@it-sudparis.eu>
Date: Mon, 24 May 2010 10:22:04 -0700
Thread-Topic: Review of draft-cheneau-csi-send-sig-agility-01
Thread-Index: Acr7RT3vwXteOT4CT1y6c3j1+r/3uAAH3bSw
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F00A75C52@NALASEXMB04.na.qualcomm.com>
References: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com> <BF345F63074F8040B58C00A186FCA57F1F00A75BD5@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.1005241451030.31700@localhost.localdomain>
In-Reply-To: <alpine.LNX.2.00.1005241451030.31700@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 17:22:42 -0000

Tony Cheneau wrote:
> 
> 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 ?

If the public key algorithm in use is signaled elsewhere (e.g. via an algorithm field in the NewSignature option) then it seems that current CGA option would be enough.

> - concerning the NewSignature, do you think we should define a new one
>    per Signature Algorithm ? 

No. We should define a NewSignature option with a field encoding the signature algorithm. (Seems that's what you call "Universal" as below.)

>    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 ?

--julien