Re: [CGA-EXT] Next steps

Tony Cheneau <tony.cheneau@it-sudparis.eu> Wed, 18 November 2009 16:15 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 404F73A6AB3 for <cga-ext@core3.amsl.com>; Wed, 18 Nov 2009 08:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BrtXOaTeyUgu for <cga-ext@core3.amsl.com>; Wed, 18 Nov 2009 08:15:36 -0800 (PST)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 18FB43A6961 for <cga-ext@ietf.org>; Wed, 18 Nov 2009 08:15:36 -0800 (PST)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 89A77FE1C74; Wed, 18 Nov 2009 17:15:33 +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 547684052E7; Wed, 18 Nov 2009 17:15:28 +0100 (CET)
Received: from pat4661.micro.int-evry.fr (unknown [157.159.103.112]) (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 3EED290011; Wed, 18 Nov 2009 17:15:28 +0100 (CET)
Date: Wed, 18 Nov 2009 17:15:40 +0100
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: Roque Gagliano <roque@lacnic.net>
In-Reply-To: <075252F1-D10D-4FFA-8EEE-C2D185DA5626@lacnic.net>
Message-ID: <alpine.LNX.2.00.0911181604410.7611@whitebox>
References: <4B03C4C7.2090708@it.uc3m.es> <075252F1-D10D-4FFA-8EEE-C2D185DA5626@lacnic.net>
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: 547684052E7.A91FF
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.399, requis 6.01, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: cga-ext@ietf.org
Subject: Re: [CGA-EXT] Next steps
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: Wed, 18 Nov 2009 16:15:37 -0000

Hello Rogue,

I have no opinion to express yet. However, can you clarify your third
proposal ? You propose to modify RFC 3971 so a CPA message contains
both a Cert AND the corresponding CRL ? This is somehow an optimization of 
your first proposal ?

Another advantage of solution 1 and 3 is that the node can verify the
validity of a prefix during the Stateless Address Autoconfiguraton
procedure, before assigning any addresses corresponding to this prefix to
an interface. This, IMHO, is an important feature.

Thanks for starting this discussion Rogue.

Regards,
 	Tony

On Wed, 18 Nov 2009, Roque Gagliano wrote:

> Marcelo,
>
> I would like to start the discussion on how the host should fetch the CRLs. This will serve as a base for a future I-D.
>
> We have at least three options:
>
> 1) To specify the  "Certificate Revocation Solicitation /  Certificate Revocation Advertisement" messages just like in SEND to request certificates.
>
> 	Advantages:
> 		- The router could cache the CRLs, which will be the same ones for most of the hosts. More-over the certs and the CRL may be pre-loaded by the router which only needs to check for a new CRL before the "next update".
> 		- Lightweight implementation at the hosts.
>
> 	Disadvantages:
> 		- Need specification, probable changes to RFC 3971.
>
> 2) To use the default fetching mechanism at the CRL Distribution Points extension for each CA. Today the only mandatory fetching mechanism is RSYNC.
> 	Advantages:
> 		- no changes in the current specifications.
>
> 	Disadvantages:
> 		- need to implement RSYNC client in hosts.
> 		- no cache, the same CRL will be fetch by every host from the source.
>
> 3) To modify the Certification Path Advertisement Message in the sense that every time a certificate is sent to the host, it will also include the CRL shown in its  CRL Distribution Points extension. So, you asked for a CERT, I send you both the CERT and the CRL (for signed with the same key).
>
> What does the WG think?
>
> Roque.
>
> -------------------------------------------------------------
> Roque Gagliano
> LACNIC
> roque@lacnic.net
> GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE
>
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext
>