Re: [Sidr] V3 draft of SIDR Charter

"william(at)elan.net" <william@elan.net> Mon, 28 November 2005 23:58 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egssr-0000pQ-V6; Mon, 28 Nov 2005 18:58:09 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egssp-0000nh-Is for sidr@megatron.ietf.org; Mon, 28 Nov 2005 18:58:09 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11793 for <sidr@ietf.org>; Mon, 28 Nov 2005 18:57:24 -0500 (EST)
Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgtCm-0002Pm-Lk for sidr@ietf.org; Mon, 28 Nov 2005 19:18:46 -0500
Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jASNvrCU015714; Mon, 28 Nov 2005 15:57:53 -0800
Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jASNvrd0015711; Mon, 28 Nov 2005 15:57:53 -0800
X-Authentication-Warning: sokol.elan.net: william owned process doing -bs
Date: Mon, 28 Nov 2005 15:57:53 -0800
From: "william(at)elan.net" <william@elan.net>
To: Geoff Huston <gih@apnic.net>
Subject: Re: [Sidr] V3 draft of SIDR Charter
In-Reply-To: <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net>
Message-ID: <Pine.LNX.4.62.0511281541570.14705@sokol.elan.net>
References: <Pine.LNX.4.64.0511101743550.23850@netcore.fi> <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <F76529DC4E8579FB25AE6E9F@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <Pine.LNX.4.62.0511280024260.14705@sokol.elan.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> <Pine.LNX.4.62.0511280138270.14705@sokol.elan.net> <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: sidr@ietf.org
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

On Tue, 29 Nov 2005, Geoff Huston wrote:

> At 11:08 PM 28/11/2005, william(at)elan.net wrote:
>> That is pretty much it. I do not see it clearly spelled out in the
>> charter that we would work on specifying access to (or at least linking 
>> rules for specifying PKI repository) PKI repositories and format of the 
>> data that is to be retrieved. There are actually quite a number of ways
>> to run a repository or certificate verification service that have been 
>> developed (plus add related issues and formats for publication of CRL
>> data as well), these are just a few these:
>>  SCVP (draft-ietf-pkix-scvp-21.txt)
>>  DVCS (RFC3029)
>>  OSCP (RFC2560)
>>  PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt)
>>  HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt)
>>  LDAP Certificate server
>>  PGP (HTTP based) key & certificate server
>>  etc.
>> And it may well be that none of the above will work because one of the key
>> issues is that BGP (like DNS) is a base protocol so one can not fully rely 
>> on some "higher" application protocol as part of BGP route establishment
>> (see also SBGP & soBGP and compare how they propose to store cert data).
>> 
>> I think info on considerations and issues involved in setting up and
>> running repositories that would be used for BGP security should be
>> considered and documented as well at least in some way.
>> 
>> Also the format for certificates and any necessary extensions are all in 
>> scope (i.e. if we decide we need extension of RFC3779) and this
>> I also see as publication-related issue.
>
> I am unsure how nmuch of this belongs in a SIDR charter and how much belongs 
> in a security area as a work item and how much is beyond the scope of

As I said before I view SIDR work as something that is more security
centric then routing but like others I personally dont care that much
if its officially under security or under routing area. But in general
IETF usually has security area WGs work on security additions to other 
protocols (when its whole WG rather then one document in WG that is
mostly working on something else).

> standards-related activities. For a charter I'm personally more comfortable 
> with the more general phrase of

> " Document the use of certification objects within this secure routing 
> architecture"
>
> and not specifying the form of repository nor the form of repository access 
> as charter work items at this point in time.

Strongly disagree. You can not attempt global deployment unless you deal 
with repository access issues.

-- 
William Leibzon
Elan Networks
william@elan.net

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr