Re: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis

Geoff Huston <gih902@gmail.com> Mon, 10 February 2014 23:01 UTC

Return-Path: <gih902@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3040E1A08B8 for <sidr@ietfa.amsl.com>; Mon, 10 Feb 2014 15:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBrLjvhXWMBP for <sidr@ietfa.amsl.com>; Mon, 10 Feb 2014 15:01:57 -0800 (PST)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 315F51A0892 for <sidr@ietf.org>; Mon, 10 Feb 2014 15:01:57 -0800 (PST)
Received: by mail-yk0-f176.google.com with SMTP id 19so9026176ykq.7 for <sidr@ietf.org>; Mon, 10 Feb 2014 15:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tKfYKfsncZMuEDlo83Lo31uWeXXpiaexYGKZ0JqrFLU=; b=WlhmdUZXsRsHEuz/s+jV+qMwX6j8ryuK/5BRR2J7GotohlFb1aPGLyjdU98o2SqbtQ z14D7HODatQtPCUu0NMUFIhxDbN1/KLbe5E76tptOWSyHO5GpJMZ01OFW+VbwcCnXFGX jD//+4Z/aR3uh1wc6cZ6S/BTOk0+W+SQeHpdVjZaN0SvOU4uK0h8V+gr7bso6pmPM6CQ hB5k5wYGW0MZEDR7c64UfyhG7YxXlUokXWTqStCWdK5qCYgpuIcdP9k0mTcd67gmhuct MMfcwQ6EoqAZD9N6eAmsb1wsENqhAd8Z5KppA1hjoO2mG0q/6qErP6RTUXiDGcyhpGww VsHA==
X-Received: by 10.236.47.162 with SMTP id t22mr3010555yhb.123.1392073316851; Mon, 10 Feb 2014 15:01:56 -0800 (PST)
Received: from [10.10.1.87] (50-201-180-2-static.hfc.comcastbusiness.net. [50.201.180.2]) by mx.google.com with ESMTPSA id 23sm51597195yhj.5.2014.02.10.15.01.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 15:01:56 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Geoff Huston <gih902@gmail.com>
In-Reply-To: <8451BEAE-465F-49AF-9AE0-DD6C8D567714@cisco.com>
Date: Tue, 11 Feb 2014 10:01:54 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE1A23E7-E654-4267-8CBF-7B1610C0D93F@gmail.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F6940A90C5@HSV-MB001.huntsville.ads.sparta.com> <m2ha8a8cb1.wl%randy@psg.com> <1B60AC34-6528-4505-B1C7-D92CA7E128D7@ripe.net> <DCAF237A-C70A-4311-9232-69499F97CE0B@gmail.com> <8451BEAE-465F-49AF-9AE0-DD6C8D567714@cisco.com>
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>
X-Mailer: Apple Mail (2.1827)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] working group adoption poll for draft-huston-sidr-rfc6490-bis
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 23:01:59 -0000

On 11 Feb 2014, at 3:23 am, Roque Gagliano (rogaglia) <rogaglia@cisco.com> wrote:

> 
> I believe you should use Section 3.2 of draft-ietf-sidr-multiple-publication-points  as a starting point. As you can see the recommended behaviour is to select a rule to fetch the TA certificate and stop when you fetch one that matches the TAL public key.
> 3.2.  Rules for Relying Parties (RP)
> 
> 
> 
>    A RP can use different rules to select the URI from where fetch the
>    Trust Anchor certificate.  Some examples are:
> 
>    o  Using the order provided in the TAL file
> 
>    o  Selecting the URI randomly from the available list
> 
>    o  Creating a prioritized list of URIs based on RP specific
>       parameters such as connection establishment delay
> 
>    If the connection to the preferred URI fails or the fetched
>    certificate public key does not match the TAL public key, the RP
>    SHOULD fetch the TA certificate from the next URI of preference.


I'll add the following to the text in section 3, and re-submit this as a -01 draft. (I hope that the wg adoption
process does not get confused by this change - is this ok WG chairs?)


   In the case where a TAL contains multiple URIs, RP may use a locally
   defined preference rule to select the URI from where fetch the Trust
   Anchor certificate.  Some examples are:
   o  Using the order provided in the TAL
   o  Selecting the URI randomly from the available list
   o  Creating a prioritized list of URIs based on RP specific
      parameters, such as connection establishment delay

   If the connection to the preferred URI fails, or the fetched CA
   certificate public key does not match the TAL public key, the RP
   SHOULD fetch the CA certificate from the next URI, according to the
   local preference ranking.


Geoff