From kseo@bbn.com Wed Apr 1 07:55:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1123228C1E3 for ; Wed, 1 Apr 2009 07:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 CRzXCHb+LS+G for ; Wed, 1 Apr 2009 07:55:20 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0F4163A6DD6 for ; Wed, 1 Apr 2009 07:53:21 -0700 (PDT) Received: from dhcp89-089-003.bbn.com ([128.89.89.3]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Lp1pa-0004uk-Ek; Wed, 01 Apr 2009 10:54:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 1 Apr 2009 10:57:13 -0400 To: Sandra Murphy From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption of draft-ietf-sidr-ta-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:55:21 -0000 I support adoption of the TA draft as a SIDR WG document. Karen From danny@tcb.net Mon Apr 6 09:05:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEAC3A6B4B for ; Mon, 6 Apr 2009 09:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.261 X-Spam-Level: * X-Spam-Status: No, score=1.261 tagged_above=-999 required=5 tests=[AWL=-2.113, BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, SUBJ_ALL_CAPS=2.077] 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 YUhONZMmQL+g for ; Mon, 6 Apr 2009 09:05:19 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 7953E3A698C for ; Mon, 6 Apr 2009 09:05:19 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 6BD812684EA; Mon, 6 Apr 2009 10:06:25 -0600 (MDT) Received: from jchouinard-sim-102.eng.ellacoya.com (97-122-114-19.hlrn.qwest.net [97.122.114.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 06 Apr 2009 10:06:25 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.114.19; client-port=50964; syn-fingerprint=65535:55:1:64:M1408,N,W3,N,N,T,S; data-bytes=0 Message-Id: From: Danny McPherson To: sidr@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 10:06:23 -0600 X-Mailer: Apple Mail (2.930.3) Subject: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:05:20 -0000 Given the DNS SEC discussions taking place regarding GOST, are there adjustments that need to be made here to accommodate this requirement as well? -danny From dburk@burkov.aha.ru Mon Apr 6 09:56:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5518C3A6987 for ; Mon, 6 Apr 2009 09:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.027 X-Spam-Level: ** X-Spam-Status: No, score=2.027 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875] 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 iRODMpA0LHgG for ; Mon, 6 Apr 2009 09:56:38 -0700 (PDT) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by core3.amsl.com (Postfix) with ESMTP id 65CC13A69C8 for ; Mon, 6 Apr 2009 09:56:37 -0700 (PDT) Received: from [83.237.58.40] (account dburk@burkov.aha.ru HELO Mys-MacBook-Pro.local) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 262233428; Mon, 06 Apr 2009 20:57:41 +0400 Message-ID: <49DA347E.8010801@burkov.aha.ru> Date: Mon, 06 Apr 2009 20:57:34 +0400 From: Dmitry Burkov User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Danny McPherson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:56:39 -0000 Danny McPherson wrote: > > Given the DNS SEC discussions taking place regarding > GOST, are there adjustments that need to be made here > to accommodate this requirement as well? Danny, I think so - as before I thought that it is necessary to correct current sidr drafts to accept multiple algorithms. It seems reasonable simply from point of view that we will need to change algorithms as they will be unacceptable (broken). Dima > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From gih@apnic.net Mon Apr 6 13:34:12 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D227D28C1A5 for ; Mon, 6 Apr 2009 13:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 WL8qaELDhgci for ; Mon, 6 Apr 2009 13:34:12 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id BA0DF28C143 for ; Mon, 6 Apr 2009 13:34:11 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A99BE110041; Tue, 7 Apr 2009 06:35:15 +1000 (EST) Message-Id: From: Geoff Huston To: Danny McPherson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 06:35:14 +1000 References: X-Mailer: Apple Mail (2.930.3) Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:34:12 -0000 Danny, Perhaps it would be appropriate in the first instance to assist WG members to get into context here by providing one or two URLs that point to these "DNS SEC discussions taking place regarding GOST" that you are referring to here. Geoff Huston [WG Co-Chair hat ON] On 07/04/2009, at 2:06 AM, Danny McPherson wrote: > > Given the DNS SEC discussions taking place regarding > GOST, are there adjustments that need to be made here > to accommodate this requirement as well? > > -danny > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From danny@tcb.net Mon Apr 6 15:46:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14743A6AEF for ; Mon, 6 Apr 2009 15:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, WEIRD_PORT=0.001] 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 doJUqyHASv+2 for ; Mon, 6 Apr 2009 15:46:56 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 9B8F03A6CE0 for ; Mon, 6 Apr 2009 15:46:52 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id CCE0E2684EA; Mon, 6 Apr 2009 16:47:58 -0600 (MDT) Received: from jchouinard-sim-102.eng.ellacoya.com (97-122-114-19.hlrn.qwest.net [97.122.114.19]) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Mon, 06 Apr 2009 16:47:58 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=97.122.114.19; client-port=56729; syn-fingerprint=65535:55:1:64:M1408,N,W1,N,N,T,S; data-bytes=0 Message-Id: <5BD4FFA0-E5B3-46EB-ADB6-7D684DD4200B@tcb.net> From: Danny McPherson To: sidr@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 6 Apr 2009 16:47:57 -0600 References: X-Mailer: Apple Mail (2.930.3) Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 22:46:57 -0000 On Apr 6, 2009, at 2:35 PM, Geoff Huston wrote: > Danny, > > Perhaps it would be appropriate in the first instance to assist WG > members to get into context here by providing one or two URLs that > point to these "DNS SEC discussions taking place regarding GOST" > that you are referring to here. I picked up on this on the (non-IETF) DNSSEC-deployment list (Subject "DNSSEC in Russia"), first message of thread included below and archive available here: However, prior to that Dmitry Burkov mentioned it to me both at the SIDR meeting - as well as at a DNS-related meeting prior to that. I saw a subsequent pointer here as well: I'm hoping folks well versed in this will assert some clue - hence my query to the list. -danny Begin forwarded message: > From: Suzanne Woolf > Date: April 1, 2009 8:18:22 AM MDT > To: "DNSSEC deployment" > Cc: ssac@icann.org > Subject: [dnssec-deployment] DNSSEC in Russia > > > Colleagues, > > Steve Crocker and I just got off the phone from remotely participating > in a session at RANS, the Russian security conference going on today, > about DNSSEC. > > We were asked to offer a general overview, including special attention > to cryptographic issues because Russia is interested in DNSSEC for .ru > but has some legal and operational constraints that make common crypto > (RSA) difficult to deploy. Veni Markovski (ICANN) was the frontman, > presenting the slides, then Steve and I did some Q&A. > > I believe the session was very constructive. We were able to answer > some questions about DNSSEC, particularly with multiple crypto > algorithms, and promote open source and open standards as enhancing > trust in situations like Russia's. > > I look forward to seeing .ru signed. > > Slidepack will be posted at ISC soonly, with thanks to the ISC staff > who worked on it, especially Brian Reid. > > > Suzanne > > ############################################################# > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > A public archive is available here: > > and older material is at > From Sandra.Murphy@cobham.com Tue Apr 7 10:14:58 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417E93A69B8 for ; Tue, 7 Apr 2009 10:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 IH0cnUNtt1AL for ; Tue, 7 Apr 2009 10:14:57 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 371AD3A6830 for ; Tue, 7 Apr 2009 10:14:56 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n37HG1EK025344 for ; Tue, 7 Apr 2009 12:16:01 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n37HG1Zw030476 for ; Tue, 7 Apr 2009 12:16:02 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 13:15:04 -0400 Date: Tue, 7 Apr 2009 13:15:04 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 07 Apr 2009 17:15:04.0318 (UTC) FILETIME=[645E21E0:01C9B7A4] Subject: Re: [sidr] request for wg adoption of draft-ietf-sidr-ta-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 17:27:58 -0000 There were more than a dozen positive replies to this request (leaving out those who replied more than once :-) ), and one caveated reply, so I am going to judge this as working group consensus to adopt the draft as a working group item. --Sandy On Wed, 25 Mar 2009, Sandra Murphy wrote: > There were objections yesterday in the sidr meeting to the way that > draft-ietf-sidr-ta-00.txt became a wg draft. > > draft-ietf-sidr-ta-00.txt was an extract of an important topic (trust > anchors) from the res certs profile document. As this was work that had > already been a working group work item, I suggested that it should be > submitted as a wg draft, rather than an individual draft. > > That decision meant that the wg missed an opportunity to explicitly accept > this draft as a working group item. > > Those who objected said that they thought the missing process step was > needed. > > So I am requesting that the working group members state whether or not they > accept draft draft-ietf-sidr-ta-00.txt as a working group draft. > > Please reply (yes or no, both are important) to the list by Thurs 2 April > 2009. > > (The deadline is Thursday rather than Wednesday because (a) it is late and > (b) that would make the deadline 1 April 2009, which would send the wrong > message.) > > --Sandy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From terry.mndrsn@gmail.com Sun Apr 12 19:36:59 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86613A6B62 for ; Sun, 12 Apr 2009 19:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 e6fwsGo5iIwU for ; Sun, 12 Apr 2009 19:36:59 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 17E813A6A09 for ; Sun, 12 Apr 2009 19:36:59 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1528872rvb.49 for ; Sun, 12 Apr 2009 19:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=HLEK3qhzNSKG4WGwZETHfSQO6NJ5dhUl173a4uxEx4c=; b=T55cqb80CEsnhY7wN+6TYfLsmKdfk03mWWYoMuPchCMgh6OkOClqJ++JltK8m1IJpK OVfCRPOWIdU7RiVuKW82NymKrNEGMYBQ+HBfocwZ25CCrrMNnBq5+amvZ6PSnOpMNuah Ju4fGqsBsr/JbgKTSx5V6Nqcr0Fr4pPwLTtVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=R3+LRD6NOxJhtyT+n8qiBT6ijIQSK98oVQ9SyqE6hO4hIeN6k4i3lhM5W+BYBm9eHF SoBdFeuBJltMiKq6ZzmAeMKDrH9RxHbLJD2mOd1LUh05JPtWQWrEUo2UWoSxGpq6T4Uv NrhU3N1ghFosBOBET+WHUHR3OOJOtmXs0inYs= Received: by 10.142.102.5 with SMTP id z5mr2411197wfb.146.1239590289414; Sun, 12 Apr 2009 19:38:09 -0700 (PDT) Received: from ?192.168.1.100? ([114.77.128.245]) by mx.google.com with ESMTPS id 31sm15237799wff.35.2009.04.12.19.38.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 19:38:09 -0700 (PDT) Sender: Terry Manderson Message-Id: From: Terry Manderson To: sidr@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 12:38:04 +1000 X-Mailer: Apple Mail (2.930.3) Subject: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 02:37:00 -0000 All, Currently in the sidr-arch draft the only RPKI certs that are meaningfully named belong to the originally issued party, ie IANA/RIR etc. There seemed to be quite some interest @SFO in why these higher level certs are named. I spent some time talking to folk about the benefits and liabilities of meaningful names in rpki certs. I seemed to collect more reason to not name the RPKI certs (ones that hold 3779 extns) across the board, than for the naming of them.. For meaningful names: Directly identifies the resource holder to any third party For no meaningful names: CPS isn't constructed to do identity checks on the resource recipient Subordinate CAs may adopt a different CPS and make naming inconsistent ISPs may not want to identify their customers to others Concern over having RPKI certs used for non SIDR uses Not all organisations do their own routing, it may be valid for XYZ Widgets LLC to outsource routing, and Techy-Person Inc would be handling all rpki private key material. (if you have others, please provide them) So, in this light I would urge the authors to remove all requirements for ANY RPKI certs to be named, including the higher order RPKI certs. This leads me to the sidr-ta draft. The ETA is not a RPKI cert. It signs the CMS blob that holds the RTA. If anywhere that naming may be important it would be the ETA. (visual inspection of who is saying that they have rights for 0/0 etc). So IANA might be named in the ETA, but it (nor any other org) should not be named in the RTA. I'm reluctant to say that the ETA MUST have a meaningful name, but to err on the side of consistency for implementation I think it would have to be "MUST". Another option is to say "SHOULD" and then mandate it through policy process outside of the IETF frame. Terry From randy@psg.com Sun Apr 12 20:35:25 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605BD3A69DC for ; Sun, 12 Apr 2009 20:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 fB8RJrdtoWXu for ; Sun, 12 Apr 2009 20:35:24 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 785B83A6935 for ; Sun, 12 Apr 2009 20:35:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtCyG-000Ch6-Us; Mon, 13 Apr 2009 03:36:33 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id 43105C46C6C; Mon, 13 Apr 2009 12:36:32 +0900 (JST) Date: Mon, 13 Apr 2009 12:36:32 +0900 Message-ID: From: Randy Bush To: Terry Manderson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 03:35:25 -0000 > For meaningful names: > Directly identifies the resource holder to any third party actually not. note that, due to trademark rules Randy's Inviting but Peculiar Epicurian can have the trade name RIPE which does not conflict with the one on singelstraat > So, in this light I would urge the authors to remove all requirements > for ANY RPKI certs to be named, including the higher order RPKI certs. this change in the document certainly did not seem to have consensus in the meeting, though sandy would be the one to judge that. > This leads me to the sidr-ta draft. wear a nose plug randy From terry.mndrsn@gmail.com Sun Apr 12 20:43:33 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E70B3A6CB9 for ; Sun, 12 Apr 2009 20:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HbFzn--i61oD for ; Sun, 12 Apr 2009 20:43:32 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id CEEA73A6C7E for ; Sun, 12 Apr 2009 20:43:32 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so934093waf.5 for ; Sun, 12 Apr 2009 20:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=kJX+jTIaERwrtfDl/eqoSXTJv7u4fxJoGFAnPi1Ayd8=; b=hqMZbMYd0LjNaR9ocCEakV0Dy04+8Bqfoys1CuLRlNKa8kmfXuZOxxFPC1mAUxPiXE cMAH2/geLsdQSabroI12PRLJ3JmCAiUYWWCvpb4lN3S1hwjQDo5H1iY9PYwy+DuEUKlS Hah0ggFb1s4ZF6gnEQVRfUuniQEslYCxT26ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=KvtbVHGSMvOjREjydeAlJ+ohapll2F6+AqESSJAYZPdQzNmtH1uJh7bjYJrVJK11GB q8iJ4mN7bbQNCbYPlgpg9kLlY7IApuqx7ZCSq3v+Q9SWABvusGJ7zALlunXuL4AIwKqU hDih8AWCSUtOMBvA9NxOVs5ijBnURW9rplg3s= Received: by 10.114.157.1 with SMTP id f1mr2982796wae.185.1239594283448; Sun, 12 Apr 2009 20:44:43 -0700 (PDT) Received: from ?192.168.1.100? ([114.77.128.245]) by mx.google.com with ESMTPS id m30sm5068241wag.12.2009.04.12.20.44.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Apr 2009 20:44:43 -0700 (PDT) Sender: Terry Manderson Message-Id: <61651B32-3930-4CFD-B195-EA9E603A3DBF@terrym.net> From: Terry Manderson To: Randy Bush In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 13:44:38 +1000 References: X-Mailer: Apple Mail (2.930.3) Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 03:43:33 -0000 On 13/04/2009, at 1:36 PM, Randy Bush wrote: >> For meaningful names: >> Directly identifies the resource holder to any third party > > actually not. note that, due to trademark rules > Randy's Inviting but Peculiar Epicurian > can have the trade name RIPE which does not conflict with the one > on singelstraat > Fair point. :-) >> So, in this light I would urge the authors to remove all requirements >> for ANY RPKI certs to be named, including the higher order RPKI >> certs. > > this change in the document certainly did not seem to have consensus > in > the meeting, though sandy would be the one to judge that. perhaps it can be brought up for consideration again now, on the list, and represented in Stockholm given that some clarification is now underway. > > >> This leads me to the sidr-ta draft. > > wear a nose plug I don't swim ;-) Terry From heather.schiller@verizonbusiness.com Mon Apr 13 08:17:19 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2303F3A6D79 for ; Mon, 13 Apr 2009 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 by0MV7TlyaWX for ; Mon, 13 Apr 2009 08:17:18 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by core3.amsl.com (Postfix) with ESMTP id 2109E3A6E82 for ; Mon, 13 Apr 2009 08:15:40 -0700 (PDT) Received: from omzismtp03.vzbi.com ([165.122.46.170]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI100F17OZXBT00@firewall.verizonbusiness.com> for sidr@ietf.org; Mon, 13 Apr 2009 15:14:23 +0000 (GMT) Received: from omzismtp03.vzbi.com ([127.0.0.1]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI10026ZOZYD400@omzismtp03.vzbi.com> for sidr@ietf.org; Mon, 13 Apr 2009 15:14:22 +0000 (GMT) Received: from [127.0.0.1] ([153.39.145.193]) by omzismtp03.vzbi.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KI10022COZXD800@omzismtp03.vzbi.com> for sidr@ietf.org; Mon, 13 Apr 2009 15:14:22 +0000 (GMT) Message-id: <49E356CD.70705@verizonbusiness.com> Date: Mon, 13 Apr 2009 11:14:21 -0400 From: Heather Schiller User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Terry Manderson References: In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 15:17:19 -0000 Terry Manderson wrote: > All, > > Currently in the sidr-arch draft the only RPKI certs that are > meaningfully named belong to the originally issued party, ie IANA/RIR etc. > > There seemed to be quite some interest @SFO in why these higher level > certs are named. I spent some time talking to folk about the benefits > and liabilities of meaningful names in rpki certs. > > I seemed to collect more reason to not name the RPKI certs (ones that > hold 3779 extns) across the board, than for the naming of them.. > > For meaningful names: > Directly identifies the resource holder to any third party > > For no meaningful names: > CPS isn't constructed to do identity checks on the resource recipient > Subordinate CAs may adopt a different CPS and make naming inconsistent > ISPs may not want to identify their customers to others We already "identify our customers to others" publicly today with SWIP... most RIR's require SWIP/RWHOIS when you assigned/allocate a netblock over a particular size. Not sure I understand why an ISP that is already required to publicly register a netblock of a given size today, would have a problem with this? > Concern over having RPKI certs used for non SIDR uses > Not all organisations do their own routing, it may be valid for XYZ > Widgets LLC to outsource routing, and Techy-Person Inc would be handling > all rpki private key material. > > > (if you have others, please provide them) > > So, in this light I would urge the authors to remove all requirements > for ANY RPKI certs to be named, including the higher order RPKI certs. > > This leads me to the sidr-ta draft. The ETA is not a RPKI cert. It signs > the CMS blob that holds the RTA. If anywhere that naming may be > important it would be the ETA. (visual inspection of who is saying that > they have rights for 0/0 etc). So IANA might be named in the ETA, but it > (nor any other org) should not be named in the RTA. > > I'm reluctant to say that the ETA MUST have a meaningful name, but to > err on the side of consistency for implementation I think it would have > to be "MUST". Another option is to say "SHOULD" and then mandate it > through policy process outside of the IETF frame. > > Terry > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From terry.mndrsn@gmail.com Mon Apr 13 15:43:05 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD6528C175 for ; Mon, 13 Apr 2009 15:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HCYTcvqgLkXf for ; Mon, 13 Apr 2009 15:43:04 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 3889A3A693A for ; Mon, 13 Apr 2009 15:43:03 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id 11so13732tim.25 for ; Mon, 13 Apr 2009 15:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=xq4ZFvOMxYHCob1JxMEljERKZTrfwSPv4L2yqbGR8MU=; b=uWXdoo7C7ZVLYsQ79v0OIURBCsiauiUuhxvEsA1ORpgHXsF74KVfOBkmzu/7RdeYK7 Ahgls6O0LMuH6y3JLvTPInsz9JheBjYAiuv7KQvXXYGdc+vdockVKCQnzPNdiC+F7nsy K2f0RCXI/R08afP2PS7jbyw5HzOFkB4tVmRwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=ezTOKDvj7FmM4aiM2Cy06L+Tl0l8PdF2yQDL6Vgk1hQ+yOlQ84uULWnG4B1Pweq86c +sDZVRfJ+vA5949Iz+CCbx+UO3IW8X8jD7k45QZeAX3U4LlaRW6KWrD+mBBHmF+6MMU9 0ZRNQvYJROyvKVQgzNjDxlAeiNvasEH/fYy+k= Received: by 10.110.5.14 with SMTP id 14mr9463459tie.40.1239662654108; Mon, 13 Apr 2009 15:44:14 -0700 (PDT) Received: from ?192.168.1.100? ([114.77.128.245]) by mx.google.com with ESMTPS id y5sm486893tia.29.2009.04.13.15.44.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 15:44:12 -0700 (PDT) Sender: Terry Manderson Message-Id: From: Terry Manderson To: Heather Schiller In-Reply-To: <49E356CD.70705@verizonbusiness.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 08:44:06 +1000 References: <49E356CD.70705@verizonbusiness.com> X-Mailer: Apple Mail (2.930.3) Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:43:05 -0000 Hi Heather, On 14/04/2009, at 1:14 AM, Heather Schiller wrote: > > > We already "identify our customers to others" publicly today with > SWIP... most RIR's require SWIP/RWHOIS when you assigned/allocate a > netblock over a particular size. Not sure I understand why an ISP > that is already required to publicly register a netblock of a given > size today, would have a problem with this? APNIC has a privacy policy: Proposal prop-007: Privacy of customer assignment records http://www.apnic.net/policy/proposals/prop-007-v001.html It varies from region to region. Terry From randy@psg.com Mon Apr 13 16:51:17 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D553A67F7 for ; Mon, 13 Apr 2009 16:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] 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 QZXVvG07UKf7 for ; Mon, 13 Apr 2009 16:51:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7D7663A69D4 for ; Mon, 13 Apr 2009 16:51:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.om) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LtVwu-000Eyr-Kl; Mon, 13 Apr 2009 23:52:24 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.om (Postfix) with ESMTP id 1D001CB3A75; Tue, 14 Apr 2009 08:52:24 +0900 (JST) Date: Tue, 14 Apr 2009 08:52:24 +0900 Message-ID: From: Randy Bush To: Heather Schiller In-Reply-To: <49E356CD.70705@verizonbusiness.com> References: <49E356CD.70705@verizonbusiness.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 23:51:17 -0000 > We already "identify our customers to others" publicly today with > SWIP some do. some don't. randy From weiler+lists.sidr@watson.org Thu Apr 16 08:56:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D932B3A6CF5 for ; Thu, 16 Apr 2009 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 N6o7f+xR42e8 for ; Thu, 16 Apr 2009 08:56:39 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1FC493A6F81 for ; Thu, 16 Apr 2009 08:56:38 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3GFvpoa059495; Thu, 16 Apr 2009 11:57:51 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3GFvomw059492; Thu, 16 Apr 2009 11:57:51 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Apr 2009 11:57:50 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Terry Manderson In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 16 Apr 2009 11:57:51 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:56:39 -0000 On Mon, 13 Apr 2009, Terry Manderson wrote: > For no meaningful names: > CPS isn't constructed to do identity checks on the resource recipient > Subordinate CAs may adopt a different CPS and make naming > inconsistent ... > So, in this light I would urge the authors to remove all > requirements for ANY RPKI certs to be named, including the higher > order RPKI certs. I concur. As convenient as is surely would be to have meaningful names for IANA and the RIRs, there's nothing eventiny another entity from issing certs with those names, and surely some tools will be written that check the names rather than the keys. Let's not lead the tool writers into such temptation. -- Sam From weiler+lists.sidr@watson.org Thu Apr 16 09:04:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0303A6F75 for ; Thu, 16 Apr 2009 09:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PpV7NeuDz-qe for ; Thu, 16 Apr 2009 09:04:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 755713A6BC6 for ; Thu, 16 Apr 2009 09:04:54 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3GG66DA060003 for ; Thu, 16 Apr 2009 12:06:07 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3GG66le060000 for ; Thu, 16 Apr 2009 12:06:06 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Apr 2009 12:06:06 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: sidr@ietf.org In-Reply-To: <49DA347E.8010801@burkov.aha.ru> Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 16 Apr 2009 12:06:07 -0400 (EDT) Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:04:55 -0000 On Mon, 6 Apr 2009, Dmitry Burkov wrote: >> Given the DNS SEC discussions taking place regarding >> GOST, are there adjustments that need to be made here >> to accommodate this requirement as well? > I think so - as before I thought that it is necessary to correct > current sidr drafts to accept multiple algorithms. To me, the meaningful question is "can we handle algorithm agility"? By that, I mean "can we, for reasons not yet specified but including discovery of weaknesses in some algorithms, cleaning introduce new algorithms"? Section 3.3 of sidr-res-certs uses a 2119 MUST when saying the Signature Algorithm field MUST be one of X, Y, or Z. By its language, that suggests that we can't handle algorithm agility. But I suspect we really can handle it. Is there any strong justification for a MUST? Can we instead use a MUST only to describe validator support and use a RECOMMENED or SHOULD when talking about certficate generation? And is there any reason why algorithm agility won't just work? -- Sam From weiler+lists.sidr@watson.org Thu Apr 16 09:13:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8083A6DFE for ; Thu, 16 Apr 2009 09:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 XhaFlHRn4cei for ; Thu, 16 Apr 2009 09:13:08 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 223CA3A67EC for ; Thu, 16 Apr 2009 09:13:08 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3GGEKq6060422; Thu, 16 Apr 2009 12:14:20 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3GGEK9w060419; Thu, 16 Apr 2009 12:14:20 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Apr 2009 12:14:20 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 16 Apr 2009 12:14:20 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] Subject names wrt sidr-ta, sidr-arch X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 16:13:08 -0000 > As convenient as is surely would be to have meaningful names for > IANA and the RIRs, there's nothing eventiny another entity from ... nothing "preventing", that is. From weiler+lists.sidr@watson.org Thu Apr 16 13:40:00 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBE63A6F41 for ; Thu, 16 Apr 2009 13:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] 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 V1J-FRjM+be8 for ; Thu, 16 Apr 2009 13:39:59 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5CE1A3A6963 for ; Thu, 16 Apr 2009 13:39:59 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3GKfBeU075088 for ; Thu, 16 Apr 2009 16:41:11 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3GKfBR8075085 for ; Thu, 16 Apr 2009 16:41:11 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Apr 2009 16:41:11 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: sidr@ietf.org In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 16 Apr 2009 16:41:11 -0400 (EDT) Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:40:00 -0000 On Thu, 16 Apr 2009, Samuel Weiler wrote: > To me, the meaningful question is "can we handle algorithm agility"? By that, > I mean "can we, for reasons not yet specified but including discovery of > weaknesses in some algorithms, cleaning introduce new algorithms"? Make that "cleanly introduce new algorithms". I'm not have good luck with the typing today. -- Sam From randy@psg.com Thu Apr 16 15:55:21 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5643E3A6E5C for ; Thu, 16 Apr 2009 15:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] 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 SrhflAJ7lnif for ; Thu, 16 Apr 2009 15:55:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 6BFCB3A6DA8 for ; Thu, 16 Apr 2009 15:55:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuaVS-000OFP-Tq; Thu, 16 Apr 2009 22:56:31 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 161DBD585BC; Fri, 17 Apr 2009 07:56:30 +0900 (JST) Date: Fri, 17 Apr 2009 07:56:29 +0900 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:55:21 -0000 > And is there any reason why algorithm agility won't just work? how do you capability negotiate with a cert? i understand how to do it with a protocol peer, but not a static object. not that i think your desire is bad, i just don't see how to get there from here. i suppose with enough complexity, ... but this is one of those time i think there is a version number in the protocol. randy From turners@ieca.com Thu Apr 16 17:29:20 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2887B3A6A44 for ; Thu, 16 Apr 2009 17:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] 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 KeIzNeeVZcnZ for ; Thu, 16 Apr 2009 17:29:19 -0700 (PDT) Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by core3.amsl.com (Postfix) with SMTP id 3366A3A6917 for ; Thu, 16 Apr 2009 17:29:19 -0700 (PDT) Received: (qmail 78084 invoked from network); 17 Apr 2009 00:30:32 -0000 Received: from unknown (HELO thunderfish.local) (turners@96.241.94.237 with plain) by smtp109.biz.mail.re2.yahoo.com with SMTP; 17 Apr 2009 00:30:31 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: bLq_7GIVM1mbDax.rc2qt3OuwbzR1KZmYcC8av58WZ1FI4Qc3hYtNIJOieK.LgK6fW2LKNo8Yd9KEJW6ijlf63PG1cVoPUVnDPCf7X7dpz97lsr9U0MK..6uNSHYnO3DLVhYUgA3tLof_fNZdetk6Hidtxga4UWLmpT7Z704zMvVCNe3GxlXzW_PeRYzpQuU1GIBu.L4_DUedaBviu6HCQeE.xuw7DYdVkwhtJe2xwpaSyiwPW0Lx0OcgFEY7JPni5Wfjby_jtyp6QdIF.RxeAcs3FeXiJr6hF5bvcFDOX9p48WzNs8lGiVXerPNo2Cubw8WMAej8kk3fejc0Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E7CDA7.2040908@ieca.com> Date: Thu, 16 Apr 2009 20:30:31 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Randy Bush References: <49DA347E.8010801@burkov.aha.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:29:20 -0000 Randy Bush wrote: >> And is there any reason why algorithm agility won't just work? > > how do you capability negotiate with a cert? i understand how to do it > with a protocol peer, but not a static object. > > not that i think your desire is bad, i just don't see how to get there > from here. > > i suppose with enough complexity, ... but this is one of those time i > think there is a version number in the protocol. I'm not saying you should do this but there's a way to indicate the other algorithms supported by the certificate holder using the S/MIME Capabilities certificate extension: http://www.ietf.org/rfc/rfc4262.txt. It's not negotiation per se but it might help. spt From Sandra.Murphy@cobham.com Mon Apr 20 14:47:39 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7CEC3A6E4C for ; Mon, 20 Apr 2009 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] 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 Zw3ZHcv0X+CC for ; Mon, 20 Apr 2009 14:47:39 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A24453A6E55 for ; Mon, 20 Apr 2009 14:46:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3KLlPdJ006961 for ; Mon, 20 Apr 2009 16:47:25 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3KLlPZk006668 for ; Mon, 20 Apr 2009 16:47:26 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 17:41:19 -0400 Date: Mon, 20 Apr 2009 17:41:18 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2009 21:41:19.0088 (UTC) FILETIME=[BD715700:01C9C200] Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:47:40 -0000 On Fri, 17 Apr 2009, Randy Bush wrote: >> And is there any reason why algorithm agility won't just work? > > how do you capability negotiate with a cert? i understand how to do it > with a protocol peer, but not a static object. I agree that it doesn't seem to be possible to negotiate, as there's only a one way communication between the two parties - signers sign, relying parties validate. But I don't see that negotiating on algorithm support is necessary. Can more than one algorithm be used in signing? My very uninformed reading of 3280 says that the algorihm of the subject public key need not be the same as the issuer's signature algorithm. Those of informed opinions should say otherwise. Can more than one algorithm be used in validating? Same uninformed opinion says that some islands could validate using one algorithm, other islands could validate using another. Of course, if one island can use *only* one algorithm, and the other island can use *only* another algorithm, then neither island can validate all RPKI certs. That's not good from the issuer's point of view, as the issuer would like its routes to be validatable everywhere. So if there are multiple algorithms for whatever reason (from politics to new crypto breakthroughs), issuers might want to produce multiple certs, one per algorithm, for each certified resource. (Could do that the other way around, also - the validators must support all algorithms, the issuers get to use a subset. However, if some validators support *some* and some issuers support *some* - it would be hard to know or predict which parts of the Internet could validate each other's routes.) In times of partial deployment of a new algorithm, any member of the side (issuer or validator) that is supposed to support all available algorithms but who does not yet support the new algorithm will be cutting themselves off from any portion of the net that uses only the new algorithm. Or at least there will be more validation answers of "indeterminate". Which sounds to me a lot like the situation we're considering now of partial deployment. Certainly having just one algorithm, period, makes this a lot more predictable. That, surely, was the reason for mandating a single signature algorithm. But it also makes agility, whether from politics or crypto changes, impossible. > > not that i think your desire is bad, i just don't see how to get there > from here. As someone has already pointed out, the security directorate has been pretty insistent on having security agility everywhere, and for good reasons. We need to consider if we can make a case that those good reasons do not apply, or that the cost is much too high. (And getting there from here would require changing only the MUST for RSA...) > > i suppose with enough complexity, ... but this is one of those time i > think there is a version number in the protocol. There is no protocol here, and the version number in the certs is fixed at "2" to represent "X.509 Version 3 certificates". I don't think that's going to change any time soon. :-) --Sandy > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From weiler+lists.sidr@watson.org Mon Apr 20 14:54:38 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAFE23A6964 for ; Mon, 20 Apr 2009 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] 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 OfPKRLwzqkqm for ; Mon, 20 Apr 2009 14:54:38 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 81A5D3A695C for ; Mon, 20 Apr 2009 14:54:37 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3KLtp63009675; Mon, 20 Apr 2009 17:55:52 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3KLtpn9009671; Mon, 20 Apr 2009 17:55:51 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 20 Apr 2009 17:55:50 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 20 Apr 2009 22:55:52 +0100 (BST) Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 21:54:38 -0000 On Fri, 17 Apr 2009, Randy Bush wrote: >> And is there any reason why algorithm agility won't just work? > > how do you capability negotiate with a cert? i understand how to do it > with a protocol peer, but not a static object. I'm not suggesting negotiation. I'm asking "will RPKI partcipants who want to use algorithms different from the norm and/or their parents be able to do so without any bad effects"? Using strange algorithms may well mean that most relying parties can't verify the certificates, but that's to be expected. > i suppose with enough complexity, ... but this is one of those time i > think there is a version number in the protocol. So long as "version number" isn't a synonym for "flag day", there's nothing wrong with having one. But we already have algorithm identifiers in the certs. Are those enough? -- Sam From randy@psg.com Mon Apr 20 15:12:01 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B983A6E4E for ; Mon, 20 Apr 2009 15:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 HhyPSG5tFiKH for ; Mon, 20 Apr 2009 15:12:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 27BA03A6D3F for ; Mon, 20 Apr 2009 15:12:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw1jm-000GnU-Ba; Mon, 20 Apr 2009 22:13:14 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id A8A9DE9345A; Mon, 20 Apr 2009 18:13:13 -0400 (EDT) Date: Mon, 20 Apr 2009 18:13:13 -0400 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:12:01 -0000 > I'm asking "will RPKI partcipants who want to use algorithms different > from the norm and/or their parents be able to do so without any bad > effects"? no > Using strange algorithms may well mean that most relying parties can't > verify the certificates, but that's to be expected. i hope you do not think this is acceptable or useful. randy From weiler+lists.sidr@watson.org Mon Apr 20 15:39:53 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF57D28C2A8 for ; Mon, 20 Apr 2009 15:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] 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 1vhUgDSJOV+r for ; Mon, 20 Apr 2009 15:39:53 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id C904528C205 for ; Mon, 20 Apr 2009 15:39:52 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3KMf8wm012940; Mon, 20 Apr 2009 18:41:08 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3KMf802012937; Mon, 20 Apr 2009 18:41:08 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 20 Apr 2009 18:41:08 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 20 Apr 2009 23:41:08 +0100 (BST) Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:39:53 -0000 On Mon, 20 Apr 2009, Randy Bush wrote: >> I'm asking "will RPKI partcipants who want to use algorithms >> different from the norm and/or their parents be able to do so >> without any bad effects"? > > no > >> Using strange algorithms may well mean that most relying parties >> can't verify the certificates, but that's to be expected. > > i hope you do not think this is acceptable or useful. Strangely enough, I do think it's useful, or at least not harmful, but I'm interested in hearing your perspective. Here's my perspective, informed in part by Dmitry's comments both here and on DNS-related lists: There may (or will) be communities that WILL NOT sign with (=issue certificates signed by) algorithm X (=RSA). They might happily sign with algorithm Y (=GOST). Some parts of the world (=that same community plus some) will be able to verify Y certificates and will gain utility from them, perhaps by authenticating route originations from within that community. To the parts of the world that can't verify algorithm Y certificates, hopefully it will be as though such certs were never issued which, if you assume incremental deployment, isn't so very bad. So I do assume a world of partial deployment, and I assume that having no certificates issued won't cut you off from the rest of the net. And I assume that having only algorithm Y certificates is no worse than having none at all. Where do you think I've gone astray? -- Sam From randy@psg.com Mon Apr 20 15:46:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235F73A695C for ; Mon, 20 Apr 2009 15:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] 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 gqR3x5ExQypX for ; Mon, 20 Apr 2009 15:46:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 065443A69FF for ; Mon, 20 Apr 2009 15:46:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw2Eq-000GrW-GL; Mon, 20 Apr 2009 22:47:27 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id A07AEE96549; Mon, 20 Apr 2009 18:45:19 -0400 (EDT) Date: Mon, 20 Apr 2009 18:45:18 -0400 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:46:14 -0000 > There may (or will) be communities that WILL NOT sign with (=issue > certificates signed by) algorithm X (=RSA). They might happily sign > with algorithm Y (=GOST). and there will be communities which run x.25 or decnet. not a problem to me. randy From Sandra.Murphy@cobham.com Mon Apr 20 16:17:33 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832563A6A39 for ; Mon, 20 Apr 2009 16:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] 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 KGYtOgJb88P9 for ; Mon, 20 Apr 2009 16:17:32 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A86323A6953 for ; Mon, 20 Apr 2009 16:17:32 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3KNIlvD008363; Mon, 20 Apr 2009 18:18:47 -0500 Received: from cronus.sandiego.ads.sparta.com ([157.185.24.3]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3KNIlfL009550; Mon, 20 Apr 2009 18:18:47 -0500 Received: from nemo.columbia.ads.sparta.com ([157.185.80.75]) by cronus.sandiego.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 16:18:47 -0700 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Apr 2009 19:17:55 -0400 Date: Mon, 20 Apr 2009 19:17:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 20 Apr 2009 23:17:55.0181 (UTC) FILETIME=[3C2EF1D0:01C9C20E] Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 23:17:33 -0000 On Mon, 20 Apr 2009, Randy Bush wrote: >> There may (or will) be communities that WILL NOT sign with (=issue >> certificates signed by) algorithm X (=RSA). They might happily sign >> with algorithm Y (=GOST). > > and there will be communities which run x.25 or decnet. not a problem > to me. Except that if a significant portion of the world uses an algorithm your validator code can't handle, then you can't validate routes to that part of the world. Which means you could be sending your packets to some destinations down some dark alley. I would think that the validation of routes is not only of benefit in packets reaching you, but in you being more confident that your packets are going where they are meant to go. (All of this "you" and "your" is only personification - I could say "one's packets", but that's just a bit too precious.) Are you really advocating a system that could not support a change of algorithm? A new algorithm means a new RPKI-v2? (How is that different from an RPKI with a new OID in the alg field?) --Sandy > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Mon Apr 20 17:28:41 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7702F3A6FBB for ; Mon, 20 Apr 2009 17:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] 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 Jln59tNYYrmO for ; Mon, 20 Apr 2009 17:28:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7437F3A6A60 for ; Mon, 20 Apr 2009 17:28:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Lw3s0-000HHi-Ro; Tue, 21 Apr 2009 00:29:54 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id E5700E9F4E5; Mon, 20 Apr 2009 20:29:51 -0400 (EDT) Date: Mon, 20 Apr 2009 20:29:51 -0400 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 00:28:41 -0000 > Except that if a significant portion of the world uses an algorithm > your validator code can't handle, then you can't validate routes to > that part of the world. like if drc decides to change in a panic because dean anderson said he broke X? > I would think that the validation of routes is not only of benefit in > packets reaching you, but in you being more confident that your > packets are going where they are meant to go. hard to disagreee with that. though, to be pedantic, we are securing, or attempting to secure, the control plane, not the data plane. > Are you really advocating a system that could not support a change of > algorithm? A new algorithm means a new RPKI-v2? i really do not think it's gonna be reasonable to add a new algorithm without serious operational planning and roll-out. if this stuff deploys successful, N years from now, there will likely be a significant part of the net that just won't except non-validatable routing data. and we can't just let chunks of the net go unroutable. i also worry that non-trivial chunks of the net may not manage their certification data well, just as they do not manage bogon filters well today. basically, i think we need a few years of experience to get a feeling for what kinds of change we can tolerate and what kinds we need. > (How is that different from an RPKI with a new OID in the alg field?) probably not much. excuse the jet lag wipeout. at least i managed to get some food. but if there is negligible difference, then why/what exactly does sam want to change? :) randy From Sandra.Murphy@cobham.com Tue Apr 21 10:16:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA8C3A6910 for ; Tue, 21 Apr 2009 10:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] 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 B158PY7QqRIG for ; Tue, 21 Apr 2009 10:16:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id BFF733A6832 for ; Tue, 21 Apr 2009 10:16:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3LHHMe1018694; Tue, 21 Apr 2009 12:17:22 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3LHHJxi003843; Tue, 21 Apr 2009 12:17:22 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.136]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 13:16:28 -0400 Date: Tue, 21 Apr 2009 13:16:25 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Apr 2009 17:16:28.0599 (UTC) FILETIME=[E862E470:01C9C2A4] Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:16:09 -0000 On Mon, 20 Apr 2009, Randy Bush wrote: >> Except that if a significant portion of the world uses an algorithm >> your validator code can't handle, then you can't validate routes to >> that part of the world. > > like if drc decides to change in a panic because dean anderson said he > broke X? > >> I would think that the validation of routes is not only of benefit in >> packets reaching you, but in you being more confident that your >> packets are going where they are meant to go. > > hard to disagreee with that. though, to be pedantic, we are securing, > or attempting to secure, the control plane, not the data plane. > >> Are you really advocating a system that could not support a change of >> algorithm? A new algorithm means a new RPKI-v2? > > i really do not think it's gonna be reasonable to add a new algorithm > without serious operational planning and roll-out. if this stuff > deploys successful, N years from now, there will likely be a significant > part of the net that just won't except non-validatable routing data. > and we can't just let chunks of the net go unroutable. > > i also worry that non-trivial chunks of the net may not manage their > certification data well, just as they do not manage bogon filters well > today. > > basically, i think we need a few years of experience to get a feeling > for what kinds of change we can tolerate and what kinds we need. > >> (How is that different from an RPKI with a new OID in the alg field?) > > probably not much. excuse the jet lag wipeout. at least i managed to > get some food. > > but if there is negligible difference, then why/what exactly does sam > want to change? :) The word "MUST" in the section about use of RSA as the signature algorithm. To something like, maybe, "mandatory to implement"? I'm guessing. --Sandy > > randy > From randy@psg.com Tue Apr 21 10:18:08 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1C93A6910 for ; Tue, 21 Apr 2009 10:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 nOP19DypYfuq for ; Tue, 21 Apr 2009 10:18:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 6CAF43A6A0D for ; Tue, 21 Apr 2009 10:18:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwJcv-000JYa-Rv; Tue, 21 Apr 2009 17:19:21 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 91400EA64EB; Tue, 21 Apr 2009 13:19:21 -0400 (EDT) Date: Tue, 21 Apr 2009 13:19:21 -0400 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 17:18:08 -0000 > To something like, maybe, "mandatory to implement"? I'm guessing. that addresses the reader. but how does this help when the writer uses an 'optional' one? randy From Sandra.Murphy@cobham.com Tue Apr 21 11:15:27 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3663A6E38 for ; Tue, 21 Apr 2009 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] 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 1oFikORTdGfz for ; Tue, 21 Apr 2009 11:15:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id A41EF3A6AFF for ; Tue, 21 Apr 2009 11:15:26 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3LIGgh2020242; Tue, 21 Apr 2009 13:16:42 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3LIGfsd007336; Tue, 21 Apr 2009 13:16:41 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.136]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 14:16:39 -0400 Date: Tue, 21 Apr 2009 14:16:38 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Apr 2009 18:16:39.0693 (UTC) FILETIME=[50C41BD0:01C9C2AD] Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:15:27 -0000 On Tue, 21 Apr 2009, Randy Bush wrote: >> To something like, maybe, "mandatory to implement"? I'm guessing. > > that addresses the reader. but how does this help when the writer > uses an 'optional' one? The writer has also implemented the "mandatory to implement" algorithm, and produces a cert with that algorithm as well. Parallel certs. (Whole set of things to worry about there as well.) --Sandy > > randy > From jmh@joelhalpern.com Tue Apr 21 11:38:55 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E4A3A6FD0 for ; Tue, 21 Apr 2009 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Jdvp-ieLfMYy for ; Tue, 21 Apr 2009 11:38:55 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 006EB3A6EDA for ; Tue, 21 Apr 2009 11:38:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EF1EB430594 for ; Tue, 21 Apr 2009 11:40:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 6443E43058B for ; Tue, 21 Apr 2009 11:40:11 -0700 (PDT) Message-ID: <49EE1300.5060907@joelhalpern.com> Date: Tue, 21 Apr 2009 14:40:00 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sidr@ietf.org References: <49DA347E.8010801@burkov.aha.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:38:55 -0000 Given the constraints of the certificates (a given certificate can only use a single algorithm) it seems to follow that the necessary mechanism to allow for migration of algorithms is that we must allow for multiple certificates for the same block, with different algorithms. This does of course produce the potential for myriad subtl inconsistency problems. But the alternative of pretending that we know now the final algorithm that we will ever want to use seems very wrong. Yours, Joel Sandra Murphy wrote: > > > On Tue, 21 Apr 2009, Randy Bush wrote: > >>> To something like, maybe, "mandatory to implement"? I'm guessing. >> >> that addresses the reader. but how does this help when the writer >> uses an 'optional' one? > > The writer has also implemented the "mandatory to implement" algorithm, > and produces a cert with that algorithm as well. > > Parallel certs. (Whole set of things to worry about there as well.) > > --Sandy > >> >> randy >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Tue Apr 21 11:51:11 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 754E83A696E for ; Tue, 21 Apr 2009 11:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] 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 GJx3+7szpSki for ; Tue, 21 Apr 2009 11:51:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id F0D6528C110 for ; Tue, 21 Apr 2009 11:50:40 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwL4W-000JlC-EX; Tue, 21 Apr 2009 18:51:56 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 37356EA6A1B; Tue, 21 Apr 2009 14:51:56 -0400 (EDT) Date: Tue, 21 Apr 2009 14:51:56 -0400 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:51:11 -0000 > The writer has also implemented the "mandatory to implement" algorithm, > and produces a cert with that algorithm as well. ^^^^^^^ > Parallel certs. gag me with a spoon randy From housley@vigilsec.com Tue Apr 21 12:33:06 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAD228C314 for ; Tue, 21 Apr 2009 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, 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 dQbvscyxHWd5 for ; Tue, 21 Apr 2009 12:33:05 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id C2C8528C2C8 for ; Tue, 21 Apr 2009 12:33:05 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8A5949A477B for ; Tue, 21 Apr 2009 15:34:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id AkMEc7fX8yIp for ; Tue, 21 Apr 2009 15:34:21 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 67B6E9A476E for ; Tue, 21 Apr 2009 15:34:29 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Apr 2009 15:24:57 -0400 To: sidr@ietf.org From: Russ Housley In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090421193429.67B6E9A476E@odin.smetech.net> Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 19:33:06 -0000 >The writer has also implemented the "mandatory to implement" algorithm, >and produces a cert with that algorithm as well. Such a thing may be necessary to transition from one algorithm to another. Well, let's get this stuff deployed, and then in a decade or more when the currently specified algorithm is showing some tarnish, we can consider algorithm transition schemes. Russ From weiler+lists.sidr@watson.org Tue Apr 21 13:56:42 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8983E3A6E91 for ; Tue, 21 Apr 2009 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] 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 xP0lJYgbgZNP for ; Tue, 21 Apr 2009 13:56:41 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A78F63A6802 for ; Tue, 21 Apr 2009 13:56:41 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3LKvrKE081294; Tue, 21 Apr 2009 16:57:54 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3LKvrZJ081291; Tue, 21 Apr 2009 16:57:53 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 21 Apr 2009 16:57:53 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Sandra Murphy In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Tue, 21 Apr 2009 21:57:54 +0100 (BST) Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 20:56:42 -0000 On Tue, 21 Apr 2009, Sandra Murphy wrote: >>> To something like, maybe, "mandatory to implement"? I'm guessing. >> >> that addresses the reader. but how does this help when the writer >> uses an 'optional' one? It doesn't. > The writer has also implemented the "mandatory to implement" algorithm, and > produces a cert with that algorithm as well. Maybe, maybe not. The constraint presently at hand says "no, we won't produce certs using both algorithms". "Mandatory to implement" does not imply "mandatory to sign with". The document DOES say "MUST..." now, and I've previously asked what the justification for that MUST is. > Parallel certs. (Whole set of things to worry about there as well.) Indeed. Hence my questions about "do we know how algorithm agility will work"? -- Sam From weiler+lists.sidr@watson.org Tue Apr 21 13:57:54 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B7728C341 for ; Tue, 21 Apr 2009 13:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 VxrvMAW2KOjD for ; Tue, 21 Apr 2009 13:57:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id CD57228C186 for ; Tue, 21 Apr 2009 13:57:53 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n3LKx8DL081351; Tue, 21 Apr 2009 16:59:09 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n3LKx8x5081348; Tue, 21 Apr 2009 16:59:08 -0400 (EDT) (envelope-from weiler+lists.sidr@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 21 Apr 2009 16:59:08 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Randy Bush In-Reply-To: Message-ID: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Tue, 21 Apr 2009 21:59:09 +0100 (BST) Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 20:57:54 -0000 On Tue, 21 Apr 2009, Randy Bush wrote: >> The writer has also implemented the "mandatory to implement" algorithm, >> and produces a cert with that algorithm as well. > ^^^^^^^ >> Parallel certs. > > gag me with a spoon AFAIK, that's pretty typical if you're aiming for real "agility". Do you know of another way? > but if there is negligible difference, then why/what exactly does > sam want to change? :) Quoting from April 16th: "Is there any strong justification for a MUST? Can we instead use a MUST only to describe validator support and use a RECOMMENED or SHOULD when talking about certficate generation?" So I'm proposing that we don't require cert generation with any particulay set of algorithms, just that the code understand a certain set. Does that clarify? -- Sam From jmh@joelhalpern.com Tue Apr 21 14:07:47 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD27328C2ED for ; Tue, 21 Apr 2009 14:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MCsYN7VFR51V for ; Tue, 21 Apr 2009 14:07:47 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 29EC928C12B for ; Tue, 21 Apr 2009 14:07:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 392524305C4 for ; Tue, 21 Apr 2009 14:09:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-189.clppva.btas.verizon.net [71.161.52.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id AEC8C4305E6 for ; Tue, 21 Apr 2009 14:09:03 -0700 (PDT) Message-ID: <49EE35E4.5020103@joelhalpern.com> Date: Tue, 21 Apr 2009 17:08:52 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sidr@ietf.org References: <49DA347E.8010801@burkov.aha.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:07:47 -0000 Maybe I am just crazy, but this seems to cause us to miss the two goals I thought we had: 1) Aiming at an end state where every router (possibly with some outside help) can verify the origin of every prefix advertisement. 2) the security-mandated ability to change algorithms over time. If we are not aiming at the first, I am missing the point of the work. If we do not try to deal with the second, aren't we inviting trouble? Yours, Joel Samuel Weiler wrote: > On Tue, 21 Apr 2009, Randy Bush wrote: > >>> The writer has also implemented the "mandatory to implement" algorithm, >>> and produces a cert with that algorithm as well. >> ^^^^^^^ >>> Parallel certs. >> >> gag me with a spoon > > AFAIK, that's pretty typical if you're aiming for real "agility". Do > you know of another way? > >> but if there is negligible difference, then why/what exactly does sam >> want to change? :) > > Quoting from April 16th: "Is there any strong justification for a MUST? > Can we instead use a MUST only to describe validator support and use a > RECOMMENED or SHOULD when talking about certficate generation?" So I'm > proposing that we don't require cert generation with any particulay set > of algorithms, just that the code understand a certain set. > > Does that clarify? > > -- Sam > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From randy@psg.com Tue Apr 21 14:54:11 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BDF3A6D86 for ; Tue, 21 Apr 2009 14:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] 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 pX+6yoTyTkUK for ; Tue, 21 Apr 2009 14:54:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 1259A3A6CFD for ; Tue, 21 Apr 2009 14:54:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LwNw4-000K7L-EE; Tue, 21 Apr 2009 21:55:24 +0000 Received: from 21.103.180.203.e.iijmobile.jp.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 2ABE1EA7271; Tue, 21 Apr 2009 17:55:24 -0400 (EDT) Date: Tue, 21 Apr 2009 17:55:23 -0400 Message-ID: From: Randy Bush To: Samuel Weiler In-Reply-To: References: <49DA347E.8010801@burkov.aha.ru> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] GOST & SIDR X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 21:54:11 -0000 >>> Parallel certs. >> gag me with a spoon > AFAIK, that's pretty typical if you're aiming for real "agility". Do > you know of another way? nope, though i am not well versed in this end of the swamp. but there is a non-trivial difference between having two equivalent blobs and two equivalent/parallel pieces of hierarchy, as in pki. the latter goes places that give me the shudders. >> but if there is negligible difference, then why/what exactly does >> sam want to change? :) > Quoting from April 16th: "Is there any strong justification for a > MUST? Can we instead use a MUST only to describe validator support > and use a RECOMMENED or SHOULD when talking about certficate > generation?" So I'm proposing that we don't require cert generation > with any particulay set of algorithms, just that the code understand a > certain set. > > Does that clarify? yes. but i am not sure why it should make me more comfortable. randy From Sandra.Murphy@cobham.com Mon Apr 27 09:49:15 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C20E3A67DB for ; Mon, 27 Apr 2009 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] 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 j-xgjEOvREvd for ; Mon, 27 Apr 2009 09:49:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 61F893A6FC6 for ; Mon, 27 Apr 2009 09:49:10 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3RGoVD3025660 for ; Mon, 27 Apr 2009 11:50:31 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3RGoVnt022455 for ; Mon, 27 Apr 2009 11:50:31 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 12:50:30 -0400 Date: Mon, 27 Apr 2009 12:50:30 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 27 Apr 2009 16:50:30.0930 (UTC) FILETIME=[466BF720:01C9C758] Subject: [sidr] sidr minutes available X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 16:49:15 -0000 Minutes of the IETF 74 meeting were uploaded to the list two weeks ago. My apologies to the list for the late notice of the posting. Final proceedings corrections are due Wednesday, May 13. Please send any comments or corrections of the minutes to the mailing list by Wednesday, May 6, to allow time to revise the minutes. --Sandy