From nobody Mon Aug 1 05:50:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8F12D9BE for ; Mon, 1 Aug 2016 05:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5VuuU5nb4fA for ; Mon, 1 Aug 2016 05:50:06 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136EA12DB31 for ; Mon, 1 Aug 2016 05:43:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:60644 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUCYZ-000GaD-1G; Mon, 01 Aug 2016 08:42:55 -0400 To: Tim Bruijnzeels References: <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> From: Stephen Kent Message-ID: <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> Date: Mon, 1 Aug 2016 08:42:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> Content-Type: multipart/alternative; boundary="------------77998F755231D8449E4DFEFA" Archived-At: Cc: Chris Morrow , sidr Subject: Re: [sidr] two stranded docuemnts - stake time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 12:50:08 -0000 This is a multi-part message in MIME format. --------------77998F755231D8449E4DFEFA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tim, > > Although I appreciate that Randy is trying to explain the case in > terms anyone can understand, it would be preferable to keep it general. agreed. > >> (Including a parenthetical note about the historical precedent of a >> Dutch court order involving RIPE is relevant and might be included.) > > If there was such a precedent, but there isn't. I have raised this > before, but again... I am familiar with the incident. While it is true that the court did not order RIPE to do anything with RPKI data, the precedent it set has often been cited as an indication of what might happen in the future. That's why the adverse actions document identifies the following cause for some types of actions: There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to generate "bogus" signed objects or remove legitimate repository data. This is the sort of more formal language I have encouraged Randy to use in the LTA use cases doc, to no avail. Steve --------------77998F755231D8449E4DFEFA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Tim,




Although I appreciate that Randy is trying to explain the case in terms anyone can understand, it would be preferable to keep it general.
agreed.

(Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.)

If there was such a precedent, but there isn't. I have raised this before, but again...
I am familiar with the incident. While it is true that the court did not order RIPE to do anything with RPKI data, the precedent it set has often been cited as an indication of what might happen in the future. That's why the adverse actions document identifies the following cause for some types of actions:
There is also the possibility that a CA or repository operator may be subject to legal measures that compel them to generate "bogus" signed objects or remove legitimate repository data.
This is the sort of more formal language I have encouraged Randy to use in the LTA use cases doc, to no avail.

Steve
--------------77998F755231D8449E4DFEFA-- From nobody Mon Aug 1 07:34:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F612D6AF for ; Mon, 1 Aug 2016 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUTC2IMNlhIV for ; Mon, 1 Aug 2016 07:34:11 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4439212D672 for ; Mon, 1 Aug 2016 07:34:11 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bUEI7-0004wf-3T; Mon, 01 Aug 2016 16:34:04 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-18.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bUEI6-0002b5-RR; Mon, 01 Aug 2016 16:34:02 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EDE272FE-7059-4DCB-BE64-39C72ABD52D3" From: Tim Bruijnzeels In-Reply-To: <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> Date: Mon, 1 Aug 2016 16:34:02 +0200 Message-Id: <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> References: <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -------- X-RIPE-Spam-Report: Spam Total Points: -8.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% [score: 0.0908] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719f2d3dea43be4a524f36ced4a031d1f2c Archived-At: Cc: Chris Morrow , sidr Subject: Re: [sidr] two stranded docuemnts - stake time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:34:16 -0000 --Apple-Mail=_EDE272FE-7059-4DCB-BE64-39C72ABD52D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Steve, > On 01 Aug 2016, at 14:42, Stephen Kent wrote: >=20 > Tim, >=20 >=20 >>=20 >> Although I appreciate that Randy is trying to explain the case in = terms anyone can understand, it would be preferable to keep it general. > agreed. >>=20 >>> (Including a parenthetical note about the historical precedent of a = Dutch court order involving RIPE is relevant and might be included.) >>=20 >> If there was such a precedent, but there isn't. I have raised this = before, but again... > I am familiar with the incident. While it is true that the court did = not order RIPE to do anything with RPKI data, the precedent it set has = often been cited as an indication of what might happen in the future. = That's why the adverse actions document identifies the following cause = for some types of actions: > There is also the possibility that a CA or repository operator may be = subject to legal measures that compel them to generate "bogus" signed = objects or remove legitimate repository data. > This is the sort of more formal language I have encouraged Randy to = use in the LTA use cases doc, to no avail. You will notice that I did NOT object to this being raised as a = possibility as such. I object to presenting a different case altogether as a precedent to = support the impression that it's not a question of if, but when this = will happen. This is not constructive. It would be lot more constructive to explain to law enforcers how such = an action would be ineffective, and ultimately counter productive. = Wording like this might help: Law enforcement would be ill-advised to take this cause of action as = it will degrade the trust that operators place in the global RPKI. Not only can operators use local = policy to circumvent the "bogus" objects - making it an ineffective measure, abuse of this power will = also lead to operators choosing not to use RPKI at all. This in turn will mean that critical = internet infrastructure will remain vulnerable to hijacks. In short it should be made clear to "law enforcement" that there is no = precedent, and that this is very much against their own interests. If = they want to ban some traffic, there are much more reliable methods at = their disposal, with much less collateral damage. Tim --Apple-Mail=_EDE272FE-7059-4DCB-BE64-39C72ABD52D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Steve,


On = 01 Aug 2016, at 14:42, Stephen Kent <kent@bbn.com> wrote:

=20 =20

Tim,




Although I appreciate that Randy is trying to = explain the case in terms anyone can understand, it would be preferable to keep it general.
agreed.

(Including a parenthetical note about the historical precedent of a Dutch court order involving RIPE is relevant and might be included.)

If there was such a precedent, but there isn't. I have raised this before, but again...
I am familiar with the incident. While it is true that the court did not order RIPE to do anything with RPKI data, the precedent it set has often been cited as an indication of what might happen in the future. That's why the adverse actions document identifies the following cause for some types of = actions:
There is also the possibility that a CA or = repository operator may be subject to legal measures that compel them to generate "bogus" signed objects or remove legitimate repository data.
This is the sort of more formal language I have encouraged Randy to use in the LTA use cases doc, to no avail.

You = will notice that I did NOT object to this being raised as a possibility = as such.

I object to presenting a = different case altogether as a precedent to support the impression that = it's not a question of if, but when this will happen.

This is not constructive.

It would be lot more constructive to explain to = law enforcers how such an action would be ineffective, and ultimately = counter productive. Wording like this might help:

    Law enforcement would be ill-advised = to take this cause of action as it will degrade the trust = that
    operators place in the global RPKI. Not = only can operators use local policy to circumvent the = "bogus"
    objects - making it an ineffective = measure, abuse of this power will also lead to operators = choosing
    not to use RPKI at all. This in turn = will mean that critical internet infrastructure will = remain
    vulnerable to hijacks.

In short it should be made clear to "law = enforcement" that there is no precedent, and that this is very much = against their own interests. If they want to ban some traffic, there are = much more reliable methods at their disposal, with much less collateral = damage.

Tim

= --Apple-Mail=_EDE272FE-7059-4DCB-BE64-39C72ABD52D3-- From nobody Mon Aug 1 09:33:31 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DDB12B01B for ; Mon, 1 Aug 2016 09:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLPFYLzYdWmo for ; Mon, 1 Aug 2016 09:33:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E0F12DCA7 for ; Mon, 1 Aug 2016 09:33:28 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:33208 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUG9X-000GjR-BK; Mon, 01 Aug 2016 12:33:19 -0400 To: Tim Bruijnzeels References: <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> From: Stephen Kent Message-ID: Date: Mon, 1 Aug 2016 12:33:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> Content-Type: multipart/alternative; boundary="------------4A3D61E4CED2E58F993B711C" Archived-At: Cc: Chris Morrow , sidr Subject: Re: [sidr] two stranded docuemnts - stake time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 16:33:30 -0000 This is a multi-part message in MIME format. --------------4A3D61E4CED2E58F993B711C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tim, I agree that the preferred approach is to persuade law enforcement folks to not view the RPKI as a new tool for taking down sites. However, I have already encountered folks in the law enforcement community who viewed it as such. I have argued that this wold be bad, but ... Given the nature of the cited court case I think it's hard to argue that a CA in the RPKI will _never_ be compelled to take action by law enforcement (or by national intelligence agencies, etc.). Thus I fear it really is a case of when, not if. Steve --------------4A3D61E4CED2E58F993B711C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Tim,

I agree that the preferred approach is to persuade law enforcement folks to not view the RPKI as a new tool for taking down sites. However, I have already encountered folks in the law enforcement community who viewed it as such. I have argued that this wold be bad, but ...

Given the nature of the cited court case I think it's hard to argue that a CA in the RPKI will never be compelled to take action by law enforcement (or by national intelligence agencies, etc.). Thus I fear it really is a case of when, not if.

Steve
--------------4A3D61E4CED2E58F993B711C-- From nobody Mon Aug 1 09:40:49 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2422812DCA7 for ; Mon, 1 Aug 2016 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oamBLy56eYsN for ; Mon, 1 Aug 2016 09:40:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0094412D1A2 for ; Mon, 1 Aug 2016 09:40:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1bUGGi-0003b3-5G; Mon, 01 Aug 2016 16:40:44 +0000 Date: Tue, 02 Aug 2016 01:40:42 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> References: <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr Subject: Re: [sidr] two stranded docuemnts - stake time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 16:40:47 -0000 you may, or may not, notice that the current i-d does not mention ripe/ncc randy From nobody Mon Aug 1 16:28:44 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FCB12D0C0 for ; Mon, 1 Aug 2016 16:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DohvMDVG8oI7 for ; Mon, 1 Aug 2016 16:28:38 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB9E12D0A8 for ; Mon, 1 Aug 2016 16:28:38 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id v123so27554132qkh.3 for ; Mon, 01 Aug 2016 16:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=swbvrkN5T6s5RpzLjLdjDoF6Psh9HDOoPYGYe/adSwI=; b=hHrH8Zc/dgcEKFxrDOoN+DzuDQ9eeICobLjNY0ZjOT31P5f5j9lWVuSvslg9WNGcjv E7OEpL+rcO1cIntwyj/ye80iYaTyycXu6lNE0szOKw1eGeBytvUpcNEA2yMvyLtQszVq lyquRFJCnFklFlAohHVFaCCK+xalE+oOY3yWE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=swbvrkN5T6s5RpzLjLdjDoF6Psh9HDOoPYGYe/adSwI=; b=BCyS2cikEzgy5KleWt04YX3QpJoeoxEFvUSnAd2+dEnuzljpaBbQYfwq8oDFsdDRBy tAZeNUJFQKNUQ0fR/3tjBYJxRdTivTbrvw1BSezDP2seItPCobPQAPaXiXBzDlmYEWVH P+Y7gRbrjQuhhZ0eTqyvdwWwCT54w+P47Q6Yu/i4CUPgQc8h5jh0Ye7Xz+P4oUhMmjJ9 xHLMwtj4Iljq4YoTxzrhxiiyuaysRbSadZN20WpNhNkYIT1I+j5C08S0ZANmbrIonMQr ACOg1ST6DCzNE4m78Li4fwa4A4af8lgO3KZl231KglLV0+Sk1ARga6yAl1Ao1p5n7AaJ i/xQ== X-Gm-Message-State: AEkooutY9a8+vwANl96a0666Uaw7+jikm1xBRRRCQdAqMdWvIodiV2j/HH8fCStO6u9Fag== X-Received: by 10.55.4.133 with SMTP id 127mr73070977qke.207.1470094117245; Mon, 01 Aug 2016 16:28:37 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id d38sm18933130qte.17.2016.08.01.16.28.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Aug 2016 16:28:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0C3063D-2CB2-49E8-8B9F-2C906A3CCA58" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> Date: Mon, 1 Aug 2016 19:28:33 -0400 Message-Id: <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> To: Rob Austein , Tim Bruijnzeels , Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF SIDR Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:28:42 -0000 --Apple-Mail=_B0C3063D-2CB2-49E8-8B9F-2C906A3CCA58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 21, 2016, at 06:36, Tim Bruijnzeels wrote: >=20 > Hi Russ, >=20 > Thank you for the pointers. I am traveling now but I will get back to = it. >=20 > Thanks > Tim >=20 >> On 21 Jul 2016, at 10:56, Russ Housley wrote: >>=20 >>=20 >> On Jul 19, 2016, at 9:14 AM, Rob Austein wrote: >>=20 >>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote: >>>>=20 >>>> Does this apply to the Certificate Policy OID too? If memory is >>>> correct, the current CP has a normative pinter to RFC 3779. >>>=20 >>> Good catch. >>>=20 >>> Not sure a policy OID change is necessary, although might be = simplest. >>> If there's a reference, we either need to change the OID or change = the >>> definition of what the OID means. >>>=20 >>> IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific >>> for the policy OID, it just follows the usual rules; it's the RP = code >>> built on top of the library that demands that particular policy OID. >>> So at least in the OpenSSL case, changing the policy OID may not = have >>> any noticeable effect on correctness of software behavior. >>=20 >> During the SIDR session today, there seemed to be some confusion = about which OIDs we are taking about. >>=20 >> The first two are from RFC 3779. They appear here in the IANA = registry: >> = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 1.3.6.1.5.5.7.1 >>=20 >> The two OIDs are:=20 >> 1.3.6.1.5.5.7.1.7 id-pe-ipAddrBlocks >> 1.3.6.1.5.5.7.1.8 id-pe-autonomousSysIds=09 >>=20 >> In addition, RFC 6484 assigned an OID for the certificate policy. It = appears here in the IANA registry: >> = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-= 1.3.6.1.5.5.7.14 >>=20 >> The OID is: >> 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber >>=20 >> I think this is a very good candidate for early IANA code point = allocation. I think that our AD can assist with that. >>=20 >> Russ To make sure I=E2=80=99m following along, to address the "Updates: 3779, = 6484, 6487 (if approved)" changes would the follow changes work: 0) RFC6484-related changes If we=E2=80=99re going with two OIDs (one for the original =E2=80=9Cstrict= " validation and one for new =E2=80=9Crelaxed=E2=80=9D validation), then = I=E2=80=99m hoping that we can just define a new OID in s1.2 of RFC 6484 = and be done with it (i.e., I hope we don=E2=80=99t also have to update = s4.1.1, s4.5.1, and s4.7.1 where RFC 3779 is mentioned). Here=E2=80=99s = some text for a new section: #.# Updates to RFC 6484 This section replaces s1.2 of [RFC6484] with the following: The name of this document is "Certificate Policy (CP) for the Resource = PKI (RPKI)=E2=80=9D. This policy has been assigned the following two OIDs: id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cp(14) 2 } id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cp(14) TBD } id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate = that the original certification path validation rules are to be used. = id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document] = indicate that the validation reconsidered certification path validation = rules defined in [this document] are to be used. 1) IANA registrations We need to register some OIDs with IANA. Here=E2=80=99s an IANA = considerations section (assumes we=E2=80=99re registering a new CP OID - = [] references will be to whatever section # it ends up being): 6. IANA Considerations IANA is to register the following five OIDs: - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI = Security for PKIX Certificate Policies registry. - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert = Section and #] in the SMI Security for PKIX Certificate Extension = registry. - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert = Section and #] in the SMI Security for PKIX Module Identifier registry. RFC EDITOR: There are two ASN.1 modules both include the same = assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2, = i.e., the assignments are made by IANA once and the values are included = in the two modules. Please delete this prior to publication. 2) RFC3799-related changes As far as RFC 3779 updates go, we probably need to update s2.3 and s3.3 = as well as add new ASN.1 modules. 2.1) I haven=E2=80=99t got text off the top of my head for the s2.3 and = s3.3 changes. 2.2) As far as the ASN.1-related changes go here=E2=80=99s two ASN.1 = module(s). The modules define the new OIDs and imports the syntax from = RFC3779/RFC6268. The basic idea is to keep the modules as short as = possible. The 2nd module is for the =E2=80=9908 ASN.1 that was defined = in RFC 6268 to be used with RFC5911/5912. #.# =E2=80=9988 ASN.1 Module IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-v2(TBD) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN -- EXPORTS ALL -- IMPORTS -- PKIX specific OIDs and arcs -- id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) = } ; -- Validation Reconsidered IP Address Delegation Extension OID -- id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } -- Validation Reconsidered IP Address Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- -- Validation Reconsidered Autonomous System Identifier Delegation = Extension OID -- id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } -- Validation Reconsidered Autonomous System Identifier Delegation = Extension Syntax -- -- Syntax is imported from [RFC3779] -- END #.# =E2=80=9908 ASN.1 Module IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2v2(TBD) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN EXPORTS ALL; IMPORTS -- PKIX specific OIDs and arcs =E2=80=94 id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn-2010 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2(72) } ; -- -- Extensions contains the set of extensions defined in this -- module -- -- These are intended to be placed in public key certificates -- and thus should be added to the CertExtensions extension -- set in PKIXImplicit-2009 defined for [RFC5280 = ] -- Extensions EXTENSION ::=3D { ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 } -- Validation Reconsidered IP Address Delegation Extension OID =E2=80= =94 ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D { SYNTAX IPAddrBlocks IDENTIFIED BY id-pe-ipAddrBlocks-v2 } id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } -- IP Address Delegation Extension Syntax =E2=80=94 -- Syntax is imported from [RFC6268] =E2=80=94 -- Validation Reconsidered Autonomous System Identifier Delegation = Extension OID =E2=80=94 ext-pe-autonomousSysIds-v2 EXTENSION ::=3D { SYNTAX ASIdentifiers IDENTIFIED BY id-pe-autonomousSysIds-v2 } id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD } -- Validation Reconsidered Autonomous System Identifier Delegation = Extension Syntax -- -- Syntax is imported from [RFC6268] -- END 2.3) If we want to be really ambitious, then right after the ASN.1 = modules are included in the draft we could request the WG chairs start = an early IANA allocation request for these OID ;) Cheers, spt --Apple-Mail=_B0C3063D-2CB2-49E8-8B9F-2C906A3CCA58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 21, 2016, at = 06:36, Tim Bruijnzeels <tim@ripe.net> wrote:

Hi = Russ,

Thank you for the pointers. I am = traveling now but I will get back to it.

Thanks
Tim

On 21 Jul 2016, at = 10:56, Russ Housley <housley@vigilsec.com> wrote:


On Jul 19, 2016, at 9:14 AM, Rob Austein = <sra@hactrn.net> = wrote:

At Tue, 19 Jul 2016 08:43:00 = -0400, Russ Housley wrote:

Does this apply to the Certificate Policy OID = too?  If memory is
correct, the current CP has a = normative pinter to RFC 3779.

Good catch.

Not sure a policy = OID change is necessary, although might be simplest.
If = there's a reference, we either need to change the OID or change the
definition of what the OID means.

IIRC, the OpenSSL library code doesn't do anything = RFC-3779-specific
for the policy OID, it just follows the = usual rules; it's the RP code
built on top of the library = that demands that particular policy OID.
So at least in = the OpenSSL case, changing the policy OID may not have
any = noticeable effect on correctness of software behavior.

During the SIDR session today, = there seemed to be some confusion about which OIDs we are taking = about.

The first two are from RFC 3779. =  They appear here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#s= mi-numbers-1.3.6.1.5.5.7.1

The two OIDs = are: 
1.3.6.1.5.5.7.1.7 = id-pe-ipAddrBlocks
1.3.6.1.5.5.7.1.8 = id-pe-autonomousSysIds

In = addition, RFC 6484 assigned an OID for the certificate policy.  It = appears here in the IANA registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#s= mi-numbers-1.3.6.1.5.5.7.14

The OID is:
= 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber

I think this is a very good candidate for = early IANA code point allocation.  I think that our AD can assist = with that.

Russ

To make sure I=E2=80=99m following = along, to address the "Updates: 3779, 6484, 6487 (if approved)" changes = would the follow changes work:

0) RFC6484-related changes

If we=E2=80=99re going = with two OIDs (one for the original =E2=80=9Cstrict" validation and one = for new =E2=80=9Crelaxed=E2=80=9D validation), then I=E2=80=99m hoping = that we can just define a new OID in s1.2 of RFC 6484 and be done with = it (i.e., I hope we don=E2=80=99t also have to update s4.1.1, s4.5.1, = and s4.7.1 where RFC 3779 is mentioned).  Here=E2=80=99s some text = for a new section:

#.#  Updates to RFC 6484

This section replaces s1.2 of [RFC6484] = with the following:

The name of this document is "Certificate Policy (CP) for the = Resource PKI (RPKI)=E2=80=9D.

This policy has been assigned the = following two OIDs:

   id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::=3D { = iso(1)
           =               = identified-organization(3) dod(6) internet(1)
                 =         security(5) mechanisms(5) pkix(7) cp(14) 2 = }

   id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::=3D = { iso(1)
           =               = identified-organization(3) dod(6) internet(1)
                 =         security(5) mechanisms(5) pkix(7) cp(14) TBD = }

id-cp-ipAddr-asNumber and the = extensions defined in [RFC3779] indicate that the original certification = path validation rules are to be used.  id-cp-ipAddr-asNumber-v2 and = the extensions defined in [this document] indicate that the validation = reconsidered certification path validation rules defined in [this = document] are to be used.


1) IANA = registrations

We= need to register some OIDs with IANA.  Here=E2=80=99s an IANA = considerations section (assumes we=E2=80=99re registering a new CP OID - = [] references will be to whatever section # it ends up being):

6. IANA = Considerations

IANA is to register the following five OIDs:

- = id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI Security = for PKIX Certificate Policies registry.

- id-pe-ipAddrBlocks-v2 and = id-pe-autonomousSysIds-v2 from [insert Section and #] in the SMI = Security for PKIX Certificate Extension registry.
- IPAddrAndASCertExtn-v2 and = IPAddrAndASCertExtn-2010v2 from [insert Section and #] in the SMI = Security for PKIX Module Identifier registry.

RFC EDITOR: There are two ASN.1 modules = both include the same assignments for id-pe-ipAddrBlocks-v2 and = id-pe-autonomousSysIds-v2, i.e., the assignments are made by IANA once = and the values are included in the two modules.  Please delete this = prior to publication.


2) RFC3799-related = changes

As far = as RFC 3779 updates go, we probably need to update s2.3 and s3.3 as well = as add new ASN.1 modules.


2.1) I haven=E2=80=99t = got text off the top of my head for the s2.3 and s3.3 changes.


2.2) As far as the ASN.1-related changes go here=E2=80=99s = two ASN.1 module(s).  The modules define the new OIDs and imports = the syntax from RFC3779/RFC6268.  The basic idea is to keep the = modules as short as possible.  The 2nd module is for the =E2=80=9908 = ASN.1 that was defined in RFC 6268 to be used with = RFC5911/5912.

#.#  =E2=80=9988 ASN.1 Module

IPAddrAndASCertExtn-v2 { iso(1) = identified-organization(3) dod(6)
   =          internet(1) security(5) mechanisms(5) = pkix(7) mod(0)
          =   id-mod-ip-addr-and-as-ident-v2(TBD) }

   DEFINITIONS EXPLICIT TAGS = ::=3D

   BEGIN

   -- EXPORTS ALL = --

   = IMPORTS

   -- PKIX specific OIDs and arcs --

     =   id-pe FROM PKIX1Explicit88 { iso(1) = identified-organization(3)
     =              dod(6) internet(1) = security(5) mechanisms(5) pkix(7)
   =                id-mod(0) = id-pkix1-explicit(18) }

   -- IP Address Block and AS Identifiers Syntax = --

= IPAddrBlocks, ASIdentifiers FROM  IPAddrAndASCertExtn { = iso(1)
            = identified-organization(3) dod(6) internet(1) security(5)
            mechanisms(5) = pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) }
    ;

   -- Validation Reconsidered IP Address Delegation = Extension OID --

= id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::=3D { id-pe TBD = }

  =  -- Validation Reconsidered IP Address Delegation Extension Syntax = --
   -- Syntax is imported = from [RFC3779] --

   -- Validation Reconsidered Autonomous System = Identifier Delegation Extension OID --

   id-pe-autonomousSysIds-v2 =  OBJECT IDENTIFIER ::=3D { id-pe TBD }

   -- Validation Reconsidered = Autonomous System Identifier Delegation Extension Syntax --
   -- Syntax is imported from [RFC3779] = --

   = END


#.#  =E2=80=9908 ASN.1 = Module

IPAddrAndASCertExtn-2010v2 { iso(1) = identified-organization(3) dod(6)
   =          internet(1) security(5) mechanisms(5) = pkix(7) mod(0)
         =    id-mod-ip-addr-and-as-ident-2v2(TBD) }

   DEFINITIONS = EXPLICIT TAGS ::=3D

   BEGIN

      EXPORTS = ALL;
      IMPORTS

     =  -- PKIX specific OIDs and arcs =E2=80=94

     =  id-pe
      FROM = PKIX1Explicit-2009
       =  { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) = mechanisms(5) pkix(7) id-mod(0)
     =      id-mod-pkix1-explicit-02(51)}
     =  EXTENSION
      FROM = PKIX-CommonTypes-2009
       =  { iso(1) identified-organization(3) dod(6) internet(1)
          security(5) = mechanisms(5) pkix(7) id-mod(0)
     =      id-mod-pkixCommon-02(57)}

   -- IP Address Block and AS = Identifiers Syntax --

      IPAddrBlocks, ASIdentifiers
      FROM IPAddrAndASCertExtn-2010
         { iso(1) = identified-organization(3) dod(6)
    =        internet(1) security(5) mechanisms(5) pkix(7) = mod(0)
          =  id-mod-ip-addr-and-as-ident-2(72) }
  =     ;

      --
   =    -- Extensions contains the set of extensions defined in = this
      -- module
      --
   =    -- These are intended to be placed in public key = certificates
      -- and thus = should be added to the CertExtensions extension
      -- set in PKIXImplicit-2009 defined = for [RFC5280]
     =  --

      Extensions EXTENSION ::=3D = {
        =  ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
      }

      -- Validation = Reconsidered IP Address Delegation Extension OID =E2=80=94

     =  ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D {
        SYNTAX = IPAddrBlocks
       =  IDENTIFIED BY id-pe-ipAddrBlocks-v2
      }

     =  id-pe-ipAddrBlocks-v2  OBJECT IDENTIFIER ::=3D { id-pe TBD = }

   =    -- IP Address Delegation Extension Syntax =E2=80=94
      -- Syntax is imported = from [RFC6268] =E2=80=94

      -- Validation = Reconsidered Autonomous System Identifier Delegation Extension OID = =E2=80=94

      ext-pe-autonomousSysIds-v2 = EXTENSION ::=3D {
       =  SYNTAX ASIdentifiers
     =    IDENTIFIED BY id-pe-autonomousSysIds-v2
      }

     =  id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD = }
   -- Validation =
Reconsidered Autonomous System Identifier Delegation Extension Syntax =
--
   -- Syntax is imported from [RFC6268] =
--

   END

2.3) If we want to be = really ambitious, then right after the ASN.1 modules are included in the = draft we could request the WG chairs start an early IANA allocation = request for these OID ;)

Cheers,

spt

= --Apple-Mail=_B0C3063D-2CB2-49E8-8B9F-2C906A3CCA58-- From nobody Tue Aug 2 01:21:49 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5290F12B035 for ; Tue, 2 Aug 2016 01:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0xlO8nqh70R for ; Tue, 2 Aug 2016 01:21:44 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4869212B004 for ; Tue, 2 Aug 2016 01:21:44 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bUUxJ-0001ul-Dm; Tue, 02 Aug 2016 10:21:42 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-36.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bUUxJ-0001LX-88; Tue, 02 Aug 2016 10:21:41 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Tue, 2 Aug 2016 10:21:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <4866b582-0016-2136-1dc6-e95946eeff78@bbn.com> <99F55C95-7589-4594-B1B1-8988682FBB46@ripe.net> <67f9b7b7-d490-1671-3b30-8c1ab73d2d12@bbn.com> <78682CEF-7643-47B9-AD73-22ADC3B653C4@ripe.net> To: Randy Bush X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: -------- X-RIPE-Spam-Report: Spam Total Points: -8.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3696] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b170cb701ecafabaf11d3457c87eaf83 Archived-At: Cc: sidr Subject: Re: [sidr] two stranded docuemnts - stake time X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 08:21:45 -0000 Hi Randy, I did. Thank you very much. Do you think that a notice to law enforcement about how this action = would be ineffective and counter-productive has a place in your = analysis? Something along the lines of what I suggested earlier: Law enforcement would be ill-advised to take this cause of action as = it will degrade the trust that operators place in the global RPKI. Not only can operators use local = policy to circumvent the "bogus" objects - making it an ineffective measure, abuse of this power will = also lead to operators choosing not to use RPKI at all. This in turn will mean that critical = internet infrastructure will remain vulnerable to hijacks. I never denied that there will be some in LEA that look at RPKI as a = knob to control routing. But rather than raising this as a given and = misquoting a different incident as legal precedence (which again it just = isn't in the legal sense - freezing contact data is a far cry from = changing routing), it would be much better if the analysis made it very = clear to LEAs that this is a very bad idea in the first place. They really should care more about protecting critical infrastructure, = governmental, military and civil - where a lot more is to be lost in = security and economic damages if the technical community turns away from = this technology, than there is to be gained by black-holing some traffic = - ineffectively and temporarily. And to operators it should be clear that the use of local policy or = exceptions (e.g. SLURM) can be used to easily circumvent such actions. Tim > On 01 Aug 2016, at 18:40, Randy Bush wrote: >=20 > you may, or may not, notice that the current i-d does not mention > ripe/ncc >=20 > randy From nobody Tue Aug 2 02:33:50 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7D812D1BE for ; Tue, 2 Aug 2016 02:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcD2Lv1yV0Ki for ; Tue, 2 Aug 2016 02:33:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8081912D10F for ; Tue, 2 Aug 2016 02:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/ZINeN66FYOE6LfHQYLQR+N3C2IriH2wE/ogf7pZ8aw=; b=RJ7rxwYpzNm11Nsf2iUqsx0pQBAOqoigTxunpA2SYbYAsd41ADviuQTidEiYKDfVqr0Y3ji0G+iaVqWBpC3nP6rQE+vtOIi21HY15tys8qUxptgU0ACwUWsZ/XQVHTqXDLQvgV8MWRnNPVKTJHdFmVudfUJCpGq3hSmf14r4PTw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.50.86.164) by HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 09:33:29 +0000 Message-ID: <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Turner , Rob Austein References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> Date: Tue, 2 Aug 2016 10:30:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [31.50.86.164] X-ClientProxiedBy: DB4PR05CA0037.eurprd05.prod.outlook.com (10.160.40.47) To HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) X-MS-Office365-Filtering-Correlation-Id: 7a770cdf-ab9b-451c-7755-08d3bab8105c X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 2:7IjKgY6t6qhS/4aVAek2iFjY5Yvq6BTcN70a7E934b5ansHAbbc+5EqCoHHEMcyxCrzF4NiwrrMDHNugKOS5mDwuHnsiZOMepEoNzx/Jo6iqtLVUChsKN9bu6dmE4JkIbri310zmTYmlfZ9mQLnofyyV1H+XdfZBhB+z55hFa1WiGGajduQvXt9aINmxA7D8; 3:ksXnRTOPfYHmXLNigYwPfpCXbVrwf8aCVtKKT9/BrohSdV0LxhR0R4lEZ6Q75blfvwRjSBBbIGwEiMOXJJ/7nExODK7hOxVAp0SlNHc10S2MGwXssy5qXtc2fkKPhs6I X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1625; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 25:kZtCBqbKtNGE/u43wCl/4/94qT+5PyqtqQC1jigahUVEYsIpy7lEcPpE6EN6ekbgquseKgqny6RkPe6lHZSZwweEVl1r2dEUTgkegGxb/+MKi0HhhGOfUEOGVplYUSRBw8siaxuwOC7YI1EnVDzO9APxC4jDc36Bc17/LmDruTouLZPpbdCkOvU1Bu3o9BE+hwXMoeJGG5gxq1LwMzaRYzs4YOnc8gr/3Tt2OxMOzzk0YtK/KTYzB+1v+UWyp6LnKSSwoLJUnv3D7zea072aMHI821oj0GRMSd/Y+HwYqyy/4Z3qp+EE6fUPhD+lEYjkNrLCY5cP+0yVUVcSyJwecKlMs59GYAgFWiSqtg7mnvRpMwnR0gCn4XEy64Xnmw6ntLuEfkYXLIfXjuamC2HQNQ4AlLgSKTfrNhrNMMQKTNNAEQyZW59s70Q/ZZBmn8mkMnwXUXa0WmZ7fEAfQdisugPzG4ohC30iE5db3DofmnA87o55Vt45ZpcNzR2ycpyTEhxrL5RiiQoeYPpT1HjUnzenwVBX8D48fe7rxzf580uog0ZapF5PJzTNnKplr38E2+/TnqMHhN6+STnOWJwotJ1VeoChK/ni0TUA0/hVBJb3POmH8l0UMjMUNO00Np/onmowLdfYzXsiA+tiGAFSsqtRSLJutuRhf9CMw7pCdq0coEHZdyqle85jUivx4uliWLfzp9tPK3VTs4AtW2TH6d9ZIBK5yVhcmpEC8vXPVsJbBTcg+pTcLd2f+UfLXptGJckINKl7+85kIH+u1U+euW9hzLbSF6nqakQl3I5eFqBAdWsURktyZyTP3WLpaXk4FJpxrlNEpVNvSjvehFvcOg== X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 31:eWACwuzAonGQuFJWWGGeeY82fP2R1O1DnwCwfnYZj8eel6HVC7jHZVRQwGJKla+gm6sUKWvhL28vWA0yN1qnwwfyOkNlVOCpjFDcZHpqXXxNmRSDu6iWqTZd7hmBwuun1FK0VR5yUnQ7IcTnROmzEsjrAuGvU0GgHm8Ir71+yT4XwMQ3NwKlNXjAEDeX+G/TlzJRNTlIfektEKnmkSGcBmJzEBkFeMvWudAnFTr59x4=; 4:QXE53zGiLtxjldrSIJEqFsS9h/P5O/1rCYZdkeN7eaxPsasMjOLA4R1ii3ejDVEEfAN1Z/pdeaaJHOAuuxiumbg99JD2iPbnYdvoCK9XG0RmtDzzYNCC0AdYvYgQ81WYAWwAe4Eo6P4b/8yeLjPS6ZLcYJbt4h8fn2gvAA6TVqDb4yXJ+zCbSwdRoBPvE132XXFpzfQhtLkEc4WGFnSxD0Gr+1Co6daMyY9jJ14i89bMaKW+rpnMhHJsmrpHU6cChwc1yP9sE0NxXkdSym14Zzx37Sfcn/FdemjX9C4SLOHkWg2ru6PBhF9u0ZhnD2N2TW2vfCG5eL4/y34tDFSJre9z/E+26P+a9Sr8aaiXL3Ogk937prNzGVb2lBVtMYm+uJTk4DxQIG5Oa6CNDgHIi8EeqgZQjQy4R231ldiz1M3/xmSUEecneAN2VDv49rUQ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1625; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1625; X-Forefront-PRVS: 0022134A87 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(377454003)(51444003)(189002)(13464003)(199003)(81166006)(33646002)(7846002)(586003)(3846002)(92566002)(5001770100001)(44736004)(7736002)(6116002)(116806002)(62236002)(2906002)(15975445007)(81156014)(305945005)(106356001)(44716002)(47776003)(23676002)(345774005)(50466002)(14496001)(8676002)(86362001)(97736004)(93886004)(50986999)(68736007)(9686002)(76176999)(189998001)(81686999)(105586002)(81816999)(4326007)(84392002)(66066001)(50226002)(1456003)(19580405001)(2870700001)(1556002)(19580395003)(42186005)(101416001)(77096005)(61296003)(74416001)(7726001)(4720700001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1625; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI1OzIzOjRadHdMRWV3eXBta3Z1N1ZRN2V3MzN4RXIr?= =?utf-8?B?WU1sUjhteVBULzIzQUJ4T2ErN3pQTDhoVUkxRkJIb0lxb3BlQ2QrSDhISlB5?= =?utf-8?B?NmRpd1Q5ZnlZZmthRktES3NURWROaURHQVJVdHBpMXJKTU5YZERnVVdHWit4?= =?utf-8?B?TXdscEV0S3ZsTy9CdEplVUlDTEF6OGxwQStHWFdYTk9PRnJQcmt5eE03WUhj?= =?utf-8?B?Qk01azdjYkd3bS9kZGRKekllWld0NVlZMHVUWUxabzExaDQ3d041QjZ0OHlt?= =?utf-8?B?STA2a1AzRkVBbTZzYm9PVnFqcmlYNzNFUXJhV1hyTWFQNENYUGFEQi84R3ly?= =?utf-8?B?b1BkUlcyNWxrUWMvWkw3bHFnVkZrMzN4UWpZTUtmV0tORVo2WlBJRmRmUEJH?= =?utf-8?B?VXdqKzI3RnRzNGZtUy9xQnpRWXU1Y0FrTjJDeExmaTYzL0MxaWN3eHFZeGJG?= =?utf-8?B?bEx4c1JMc0hCYkI2RUdHWFZTSGdISUlrbTFISXRZZ0M1eThCbldZb0hUZDBs?= =?utf-8?B?RlE5MmhtZlpPd0NkeHd3ZlFwcVQzb0QrbS93a29IdUhGVGdvWHM2ZGpROVVq?= =?utf-8?B?a0kxRHRDZUoyTVVmc1ROT05RK0IvTGw4YlV0alZRbW1jdVRZQUhVcDVBbW1y?= =?utf-8?B?RU4wWXlxZmlISHFzb3ZEek9aRG1KUjd3MEYzT3dyOEVreXBGZnM1eTFPb2pq?= =?utf-8?B?NUFVRVFxQWZudFliSWc0bFZZUitNaFBiaTVwWENmaEJvM2dVcDhBenFiOFhF?= =?utf-8?B?VUx6MlZsVGRlWCtqTWlDVW9NMGw5NE5GNXIzZElLWlN6VXhEaHhuR2NpNVJG?= =?utf-8?B?S3JTVDVzNTgwVU81eHQzN2xjU0JLRUJ2VDgxNVVzUTQvZVBvRHc4Z1hoUFVY?= =?utf-8?B?bmZNbFBRc3lUeTVFR0Z1cWpycGEvTkROM1N2anpoYmFFNk9WUHZzWkZ5Sm1j?= =?utf-8?B?dXoySkRTNEN2Y2NoSnhHQVVyMjVZU3FmYkIzbGsvMDVYZHhpYkhsTTlJZGdi?= =?utf-8?B?NDZQUVFlWVVTeTgxZnRuSFdkelJwaGVST1JDUE92RkZmR0liUnN3NmM1dVUv?= =?utf-8?B?WTVNbzhNWnlBUkxtMkxFemwyaGFBR01UY2RCdmh6QldnRjR0b1VweG9mZjR6?= =?utf-8?B?d2hRT0FNYURpdmUxZFVhQkNnMWlUMWNJZ0E2NzVxdDNxL2Rya1lPRElvcTZY?= =?utf-8?B?dEVIV2JOaDM4dnRtMGdGbTVwckp6U0Q1Nld4OTczRno0WEx5Q25ZQWZzQlNP?= =?utf-8?B?a1RUdWRrVXRuUzZQNFdraVBrZFQ0RDZObksrSXIvWjgvaFUvckJoNEVDU2cw?= =?utf-8?B?Z3h2RFl5Mk5MN1VQeUlHYy9xb0FoemNmOWt6UE5SL3E3Q1BiQVlZZThpY2tp?= =?utf-8?B?NDJON3JjQTlSbitWR09kYnEvWEF0d3NCcEZOZ3EzaDlHc2dlejdIRUYwaHhs?= =?utf-8?B?aFZDNnZpYlAwN2Z0WUthbUFVTDRIdW5xeEJUUFVQYWYzd2d3Q3RKak5sK0sv?= =?utf-8?B?M3B4TkpSeXJYN0NEYzlXbXBoNExzTllXa25iM0lnRjFERUQ5ME1uWnA0ODNT?= =?utf-8?B?NVBFd3ZORmFjUXBlRVZQckRoRUZiOEVSV0NpV0Q5ais3Yi9CV01Gcmdhb1dJ?= =?utf-8?B?T1YyYTF4Q3pvN3JvUzR3RnhjVkQ2d2NmekZRUFFFZFJvNmJxOHFabmI2eXBo?= =?utf-8?B?dklFVkNGSVB5ckxYQXJTOWdrQ2VjbkdqK0FkN2NWeXQreGxHKy9DbXF2SFVQ?= =?utf-8?B?SnJoNDBsbGdkTngxL1BWajUzQ3NoZlpqbzF4L25JNlVtQ0M2Uko0VmxSbGcz?= =?utf-8?B?ZWlFQkRaRWFxcG9JamRxaU02bWp2WVkzTWlIaXhCQ25ITDBBTHpzd2oyc2FQ?= =?utf-8?B?OXptQVpqQzZxZVBPVG1UTjR3OHNDSTZUcWFYcXI1UDJLbjVtODRBOFdtU29k?= =?utf-8?B?bnptdE5GTXZ3Um5ER1hjaTIyM3F1eXRYNnBOMlVLUjJ0K21Wa1FqVGppenli?= =?utf-8?B?VWdJTnc4SUFyZE5xUkVQNTBoVHRtc0RaVXpEZz09?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 6:Bw9C66I8MAWv6yv/NBUob2SYMNwuWr4kXAmPiiz12wN/Ej9TClx0ewOg1pUX0K/4ceM5k8rPGx7pxz6VuPj/Q/k7Wcsz4GIlWyxmujaBlmpgk785vaLDAMw7pKP0CbjVMGkKQ5+p8XGk2omY96KkrFeo/osfdBhwHp66nP04u5+l4M9nUHmF2w4jYWKBz5rAbdMKoIFf5dePTj493hdFGctERlFYHqDlumdi9LJKl/i1ACxrLhuknKH3WDN9g/jpCMe48AXT2U0Yf4e8tdHZ1xEqV2XZChzRF6KQhMNkWII=; 5:66XmEaJh7jy4pCoRKYlstQ7sDp5PBImyY95UHLDuTFhYHtJD65Iltw/S67QMNZ1eFUI4NtS83b+qvnYvUuBByEICLuzos0/2+3UW4Ln2GvVoVhrxVt2wQMqXE7f6WCsH4zhq0mPa4pSZDwk8eMnU3g==; 24:ZykMrtgvuALQbUQMUXw2MTiK+LadC3Vmy05/AtyIAltluTmbDZwSxDC9fDN29f47Yna/EziPeFhe0OfW7e6ID8W3Nmqd0a/i8cch/H8wb30=; 7:TXZeHMVzvsTPUxRxln/2cvU3WvIpwB+lPVV03jAyn1aJ4vo7JeFrWmgSfVMmHpwZ6KqhXIgzzMqM66E/KQQA7TTq8WMmxUd2qH8TLXENWAhGrJOL+YvwZaHFozmMoWqUyt409SicCfes7nP9sTU2n5LXcISqPE8u4z77qhjYcVIYNX4gYEDoBafZE5NR30Fzaeil0cFmcEKGfX5YdoC1WrynMSBb2JMFxj9X+Df81KbBZhow6aROS47sEeibWOmm SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 09:33:29.4970 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1625 Archived-At: Cc: IETF SIDR Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 09:33:49 -0000 Sean I am a fan of giving IANA as little a need to think as possible so would prefer the IANA considerations to be more expansive. With three registries being updated, I would like to see three paragraphs and, with five numbers, would like to see TBD1 to TBD5, not TBD times five, e.g. IANA is asked to add to the SMI Security for PKIX Certificate Policies registry. Decimal Description References TBD1 id-cp-ipAddr-asNumber-v2 [this RFC] coupled with id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cp(14) TBD1 } replacing the TBD1 if an early allocation succeeds. Tom Petch ----- Original Message ----- From: "Sean Turner" To: "Rob Austein" ; "Tim Bruijnzeels" ; "Russ Housley" Cc: "IETF SIDR" Sent: Tuesday, August 02, 2016 12:28 AM > On Jul 21, 2016, at 06:36, Tim Bruijnzeels wrote: > > Hi Russ, > > Thank you for the pointers. I am traveling now but I will get back to it. > > Thanks > Tim > >> On 21 Jul 2016, at 10:56, Russ Housley wrote: >> >> >> On Jul 19, 2016, at 9:14 AM, Rob Austein wrote: >> >>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote: >>>> >>>> Does this apply to the Certificate Policy OID too? If memory is >>>> correct, the current CP has a normative pinter to RFC 3779. >>> >>> Good catch. >>> >>> Not sure a policy OID change is necessary, although might be simplest. >>> If there's a reference, we either need to change the OID or change the >>> definition of what the OID means. >>> >>> IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific >>> for the policy OID, it just follows the usual rules; it's the RP code >>> built on top of the library that demands that particular policy OID. >>> So at least in the OpenSSL case, changing the policy OID may not have >>> any noticeable effect on correctness of software behavior. >> >> During the SIDR session today, there seemed to be some confusion about which OIDs we are taking about. >> >> The first two are from RFC 3779. They appear here in the IANA registry: >> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number s-1.3.6.1.5.5.7.1 >> >> The two OIDs are: >> 1.3.6.1.5.5.7.1.7 id-pe-ipAddrBlocks >> 1.3.6.1.5.5.7.1.8 id-pe-autonomousSysIds >> >> In addition, RFC 6484 assigned an OID for the certificate policy. It appears here in the IANA registry: >> http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number s-1.3.6.1.5.5.7.14 >> >> The OID is: >> 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber >> >> I think this is a very good candidate for early IANA code point allocation. I think that our AD can assist with that. >> >> Russ To make sure I’m following along, to address the "Updates: 3779, 6484, 6487 (if approved)" changes would the follow changes work: 0) RFC6484-related changes If we’re going with two OIDs (one for the original “strict" validation and one for new “relaxed” validation), then I’m hoping that we can just define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I hope we don’t also have to update s4.1.1, s4.5.1, and s4.7.1 where RFC 3779 is mentioned). Here’s some text for a new section: #.# Updates to RFC 6484 This section replaces s1.2 of [RFC6484] with the following: The name of this document is "Certificate Policy (CP) for the Resource PKI (RPKI)”. This policy has been assigned the following two OIDs: id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cp(14) 2 } id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) cp(14) TBD } id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate that the original certification path validation rules are to be used. id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document] indicate that the validation reconsidered certification path validation rules defined in [this document] are to be used. 1) IANA registrations We need to register some OIDs with IANA. Here’s an IANA considerations section (assumes we’re registering a new CP OID - [] references will be to whatever section # it ends up being): 6. IANA Considerations IANA is to register the following five OIDs: - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI Security for PKIX Certificate Policies registry. - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert Section and #] in the SMI Security for PKIX Certificate Extension registry. - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert Section and #] in the SMI Security for PKIX Module Identifier registry. RFC EDITOR: There are two ASN.1 modules both include the same assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2, i.e., the assignments are made by IANA once and the values are included in the two modules. Please delete this prior to publication. 2) RFC3799-related changes As far as RFC 3779 updates go, we probably need to update s2.3 and s3.3 as well as add new ASN.1 modules. 2.1) I haven’t got text off the top of my head for the s2.3 and s3.3 changes. 2.2) As far as the ASN.1-related changes go here’s two ASN.1 module(s). The modules define the new OIDs and imports the syntax from RFC3779/RFC6268. The basic idea is to keep the modules as short as possible. The 2nd module is for the ’08 ASN.1 that was defined in RFC 6268 to be used with RFC5911/5912. #.# ’88 ASN.1 Module IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-v2(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS -- PKIX specific OIDs and arcs -- id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ; -- Validation Reconsidered IP Address Delegation Extension OID -- id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD } -- Validation Reconsidered IP Address Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- -- Validation Reconsidered Autonomous System Identifier Delegation Extension OID -- id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD } -- Validation Reconsidered Autonomous System Identifier Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- END #.# ’08 ASN.1 Module IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2v2(TBD) } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS -- PKIX specific OIDs and arcs — id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn-2010 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2(72) } ; -- -- Extensions contains the set of extensions defined in this -- module -- -- These are intended to be placed in public key certificates -- and thus should be added to the CertExtensions extension -- set in PKIXImplicit-2009 defined for [RFC5280 ] -- Extensions EXTENSION ::= { ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 } -- Validation Reconsidered IP Address Delegation Extension OID — ext-pe-ipAddrBlocks-v2 EXTENSION ::= { SYNTAX IPAddrBlocks IDENTIFIED BY id-pe-ipAddrBlocks-v2 } id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD } -- IP Address Delegation Extension Syntax — -- Syntax is imported from [RFC6268] — -- Validation Reconsidered Autonomous System Identifier Delegation Extension OID — ext-pe-autonomousSysIds-v2 EXTENSION ::= { SYNTAX ASIdentifiers IDENTIFIED BY id-pe-autonomousSysIds-v2 } id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD } -- Validation Reconsidered Autonomous System Identifier Delegation Extension Syntax -- -- Syntax is imported from [RFC6268] -- END 2.3) If we want to be really ambitious, then right after the ASN.1 modules are included in the draft we could request the WG chairs start an early IANA allocation request for these OID ;) Cheers, spt ------------------------------------------------------------------------ -------- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Aug 2 06:28:18 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCCA12D59B for ; Tue, 2 Aug 2016 06:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNqa6unn2Cbs for ; Tue, 2 Aug 2016 06:28:14 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAE912D5B5 for ; Tue, 2 Aug 2016 06:20:17 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id v123so41280309qkh.3 for ; Tue, 02 Aug 2016 06:20:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDL08e6kGReCJ0hHI9sq2lalBPREG9rIqkZ/Edo0U9o=; b=mix6NSh+OoYZ6WvqY+nqfFeaVnBcZdyC7pwnVvVgrkjQhbAllQUUrULO9Qef18+/xe iY452389hIM6qZILy0y7jJFCWr/3+zS6wkpXkPpcr/SCP2fYcYw1wJQpLzfFuhrWIGJG yqFhgJoV8A6Jgc649PRw3mhJ7gUP6fqWhZ/DE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VDL08e6kGReCJ0hHI9sq2lalBPREG9rIqkZ/Edo0U9o=; b=RWE8U3uSzD2swDRVWH4Ea8n+SbJoLqAhL9dAPK02rRHIkFh+JlCArZOT4R1VmkssMZ XJ1iZGK5lcVrge7oBP6TGG8yhw8ziUqJJpD0CfozWX7PODisOKHbJ6H54/7pmAZepeZa /+ur902jqetLw8E9+FBWrc+ByYJZGDqPh76sw1l/ttGoL3VpkqI32mKsk01VGqy08Bda SiJOPX56ZLIOYEGZLM9NmDI9TwJONtJrsf0fVuTaTzCMxl2Spfa06p4w9JLza+dJHudo Y4Tic4mW6RJZ+3B7qL4TZhcfelRxXADCnxAVgsf4QhlYMG1jEbFBIJVa3TbQgpwqzpFA KeiA== X-Gm-Message-State: AEkooutYyGr6o83CzxjFkltu6oCkjEm8cAh9W0b5E5uQypODQJvAsXtM31c/mqf+w0JzaQ== X-Received: by 10.55.180.2 with SMTP id d2mr75675351qkf.69.1470144016334; Tue, 02 Aug 2016 06:20:16 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-123-93.washdc.east.verizon.net. [173.73.123.93]) by smtp.gmail.com with ESMTPSA id 50sm1322823qts.11.2016.08.02.06.20.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Aug 2016 06:20:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Sean Turner X-Priority: 3 In-Reply-To: <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> Date: Tue, 2 Aug 2016 09:20:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <89AE2EA7-BF74-4A59-9C6C-9F50595458D8@sn3rd.com> References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Rob Austein , IETF SIDR Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 13:28:16 -0000 On Aug 02, 2016, at 05:30, t.petch wrote: >=20 > Sean >=20 > I am a fan of giving IANA as little a need to think as possible so = would > prefer the IANA considerations to be more expansive. With three > registries being updated, I would like to see three paragraphs and, = with > five numbers, would like to see TBD1 to TBD5, not TBD times five, e.g. I guess I=E2=80=99m not as paranoid as you, but #ing the TBDs would = definitely make it clearer to IANA and the RFC where the values are = supposed to go. If =E2=80=9CTBD1" is replaces the =E2=80=9CTBD" in the 6484 updates = section then the 2 & 3 are the modules and 4 and 5 are the extensions. = Revised modules follow what I think you=E2=80=99re asking for wrt the = IANA considerations section: #.# IANA Considerations IANA is to add the following to the SMI Security for PKIX Certificate = Policies registry: Decimal Description References TBD1 id-cp-ipAddr-asNumber-v2 [this RFC] IANA is to add the following to the SMI Security for PKIX Module = Identifier registry: Decimal Description References TBD2 IPAddrAndASCertExtn-v2 [this RFC] TBD3 IPAddrAndASCertExtn-2010v2 [this RFC] IANA is to add the following to the SMI Security for PKIX Certificate = Extension registry: Decimal Description References TBD4 id-pe-ipAddrBlocks-v2 [this RFC] TBD5 id-pe-autonomousSysIds-v2 [this RFC] #.# =E2=80=9988 ASN.1 Module IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-v2(TBD2) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN -- EXPORTS ALL -- IMPORTS -- PKIX specific OIDs and arcs -- id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) = } ; -- Validation Reconsidered IP Address Delegation Extension OID -- id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD4 } -- Validation Reconsidered IP Address Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- -- Validation Reconsidered Autonomous System Identifier Delegation = Extension OID -- id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD5 } -- Validation Reconsidered Autonomous System Identifier Delegation = Extension Syntax -- -- Syntax is imported from [RFC3779] -- END #.# =E2=80=9908 ASN.1 Module IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2v2(TBD3) } DEFINITIONS EXPLICIT TAGS ::=3D BEGIN EXPORTS ALL; IMPORTS -- PKIX specific OIDs and arcs =E2=80=94 id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn-2010 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2(72) } ; -- -- Extensions contains the set of extensions defined in this -- module -- -- These are intended to be placed in public key certificates -- and thus should be added to the CertExtensions extension -- set in PKIXImplicit-2009 defined for [RFC5280] -- Extensions EXTENSION ::=3D { ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 } -- Validation Reconsidered IP Address Delegation Extension OID =E2=80= =94 ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D { SYNTAX IPAddrBlocks IDENTIFIED BY id-pe-ipAddrBlocks-v2 } id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD4 } -- IP Address Delegation Extension Syntax =E2=80=94 -- Syntax is imported from [RFC6268] =E2=80=94 -- Validation Reconsidered Autonomous System Identifier Delegation = Extension OID =E2=80=94 ext-pe-autonomousSysIds-v2 EXTENSION ::=3D { SYNTAX ASIdentifiers IDENTIFIED BY id-pe-autonomousSysIds-v2 } id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD5 } -- Validation Reconsidered Autonomous System Identifier Delegation = Extension Syntax -- -- Syntax is imported from [RFC6268] -- END > ----- Original Message ----- > From: "Sean Turner" > To: "Rob Austein" ; "Tim Bruijnzeels" ; > "Russ Housley" > Cc: "IETF SIDR" > Sent: Tuesday, August 02, 2016 12:28 AM >=20 >> On Jul 21, 2016, at 06:36, Tim Bruijnzeels wrote: >>=20 >> Hi Russ, >>=20 >> Thank you for the pointers. I am traveling now but I will get back to > it. >>=20 >> Thanks >> Tim >>=20 >>> On 21 Jul 2016, at 10:56, Russ Housley wrote: >>>=20 >>>=20 >>> On Jul 19, 2016, at 9:14 AM, Rob Austein wrote: >>>=20 >>>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote: >>>>>=20 >>>>> Does this apply to the Certificate Policy OID too? If memory is >>>>> correct, the current CP has a normative pinter to RFC 3779. >>>>=20 >>>> Good catch. >>>>=20 >>>> Not sure a policy OID change is necessary, although might be > simplest. >>>> If there's a reference, we either need to change the OID or change > the >>>> definition of what the OID means. >>>>=20 >>>> IIRC, the OpenSSL library code doesn't do anything = RFC-3779-specific >>>> for the policy OID, it just follows the usual rules; it's the RP > code >>>> built on top of the library that demands that particular policy = OID. >>>> So at least in the OpenSSL case, changing the policy OID may not > have >>>> any noticeable effect on correctness of software behavior. >>>=20 >>> During the SIDR session today, there seemed to be some confusion > about which OIDs we are taking about. >>>=20 >>> The first two are from RFC 3779. They appear here in the IANA > registry: >>>=20 > = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number > s-1.3.6.1.5.5.7.1 >>>=20 >>> The two OIDs are: >>> 1.3.6.1.5.5.7.1.7 id-pe-ipAddrBlocks >>> 1.3.6.1.5.5.7.1.8 id-pe-autonomousSysIds >>>=20 >>> In addition, RFC 6484 assigned an OID for the certificate policy. = It > appears here in the IANA registry: >>>=20 > = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number > s-1.3.6.1.5.5.7.14 >>>=20 >>> The OID is: >>> 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber >>>=20 >>> I think this is a very good candidate for early IANA code point > allocation. I think that our AD can assist with that. >>>=20 >>> Russ >=20 > To make sure I=E2=80=99m following along, to address the "Updates: = 3779, 6484, > 6487 (if approved)" changes would the follow changes work: >=20 > 0) RFC6484-related changes >=20 > If we=E2=80=99re going with two OIDs (one for the original =E2=80=9Cstri= ct" validation > and one for new =E2=80=9Crelaxed=E2=80=9D validation), then I=E2=80=99m = hoping that we can just > define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I hope > we don=E2=80=99t also have to update s4.1.1, s4.5.1, and s4.7.1 where = RFC 3779 > is mentioned). Here=E2=80=99s some text for a new section: >=20 > #.# Updates to RFC 6484 >=20 > This section replaces s1.2 of [RFC6484] with the following: >=20 > The name of this document is "Certificate Policy (CP) for the Resource > PKI (RPKI)=E2=80=9D. >=20 > This policy has been assigned the following two OIDs: >=20 > id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) cp(14) 2 } >=20 > id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) cp(14) TBD } >=20 > id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate > that the original certification path validation rules are to be used. > id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document] > indicate that the validation reconsidered certification path = validation > rules defined in [this document] are to be used. >=20 >=20 > 1) IANA registrations >=20 > We need to register some OIDs with IANA. Here=E2=80=99s an IANA = considerations > section (assumes we=E2=80=99re registering a new CP OID - [] = references will be > to whatever section # it ends up being): >=20 > 6. IANA Considerations >=20 > IANA is to register the following five OIDs: >=20 > - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI > Security for PKIX Certificate Policies registry. >=20 > - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert > Section and #] in the SMI Security for PKIX Certificate Extension > registry. >=20 > - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert > Section and #] in the SMI Security for PKIX Module Identifier = registry. >=20 > RFC EDITOR: There are two ASN.1 modules both include the same > assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2, > i.e., the assignments are made by IANA once and the values are = included > in the two modules. Please delete this prior to publication. >=20 >=20 > 2) RFC3799-related changes >=20 > As far as RFC 3779 updates go, we probably need to update s2.3 and = s3.3 > as well as add new ASN.1 modules. >=20 >=20 > 2.1) I haven=E2=80=99t got text off the top of my head for the s2.3 = and s3.3 > changes. >=20 >=20 > 2.2) As far as the ASN.1-related changes go here=E2=80=99s two ASN.1 = module(s). > The modules define the new OIDs and imports the syntax from > RFC3779/RFC6268. The basic idea is to keep the modules as short as > possible. The 2nd module is for the =E2=80=9908 ASN.1 that was = defined in RFC > 6268 to be used with RFC5911/5912. >=20 > #.# =E2=80=9988 ASN.1 Module >=20 > IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-v2(TBD) } >=20 > DEFINITIONS EXPLICIT TAGS ::=3D >=20 > BEGIN >=20 > -- EXPORTS ALL -- >=20 > IMPORTS >=20 > -- PKIX specific OIDs and arcs -- >=20 > id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } >=20 > -- IP Address Block and AS Identifiers Syntax -- >=20 > IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) > identified-organization(3) dod(6) internet(1) security(5) > mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident(30) } > ; >=20 > -- Validation Reconsidered IP Address Delegation Extension OID -- >=20 > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >=20 > -- Validation Reconsidered IP Address Delegation Extension Syntax -- > -- Syntax is imported from [RFC3779] -- >=20 > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension OID -- >=20 > id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >=20 > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC3779] -- >=20 > END >=20 >=20 > #.# =E2=80=9908 ASN.1 Module >=20 > IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2v2(TBD) } >=20 > DEFINITIONS EXPLICIT TAGS ::=3D >=20 > BEGIN >=20 > EXPORTS ALL; > IMPORTS >=20 > -- PKIX specific OIDs and arcs =E2=80=94 >=20 > id-pe > FROM PKIX1Explicit-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkix1-explicit-02(51)} >=20 > EXTENSION > FROM PKIX-CommonTypes-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkixCommon-02(57)} >=20 > -- IP Address Block and AS Identifiers Syntax -- >=20 > IPAddrBlocks, ASIdentifiers > FROM IPAddrAndASCertExtn-2010 > { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2(72) } > ; >=20 > -- > -- Extensions contains the set of extensions defined in this > -- module > -- > -- These are intended to be placed in public key certificates > -- and thus should be added to the CertExtensions extension > -- set in PKIXImplicit-2009 defined for [RFC5280 > ] > -- >=20 > Extensions EXTENSION ::=3D { > ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 > } >=20 > -- Validation Reconsidered IP Address Delegation Extension OID = =E2=80=94 >=20 > ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D { > SYNTAX IPAddrBlocks > IDENTIFIED BY id-pe-ipAddrBlocks-v2 > } >=20 > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >=20 > -- IP Address Delegation Extension Syntax =E2=80=94 > -- Syntax is imported from [RFC6268] =E2=80=94 >=20 > -- Validation Reconsidered Autonomous System Identifier = Delegation > Extension OID =E2=80=94 >=20 > ext-pe-autonomousSysIds-v2 EXTENSION ::=3D { > SYNTAX ASIdentifiers > IDENTIFIED BY id-pe-autonomousSysIds-v2 > } >=20 > id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD } > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC6268] -- >=20 > END >=20 > 2.3) If we want to be really ambitious, then right after the ASN.1 > modules are included in the draft we could request the WG chairs start > an early IANA allocation request for these OID ;) >=20 > Cheers, >=20 > spt >=20 >=20 >=20 >=20 > = ------------------------------------------------------------------------ > -------- >=20 >=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 From nobody Tue Aug 2 09:35:54 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFB312D802 for ; Tue, 2 Aug 2016 09:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALVCKq0lnxUR for ; Tue, 2 Aug 2016 09:35:49 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0131.outbound.protection.outlook.com [104.47.0.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4CC12D0C7 for ; Tue, 2 Aug 2016 09:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p5B+B1V/aGu3iocvKVe8McsHbjdqbkMWO4WTYNZolsA=; b=fYHlDgtzqK4XYPZ1xLZYF+iftCh/qMQlZ/VYGM2MIZIauI/9RHwRFIjhCCDyVlS1prXBlbWFK3/jxaBL4vBn5n+YiA+UUtn7guCAg/10H8CQn7ZSxr1zOZNx9ktfbebdmsbGy9WY2846n1qP6Z7Ibhny8Vs4TO+iagDAdW9cf9o= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.50.86.164) by DB5PR07MB1624.eurprd07.prod.outlook.com (10.166.12.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Tue, 2 Aug 2016 16:35:43 +0000 Message-ID: <00c201d1ecdb$8d45a640$4001a8c0@gateway.2wire.net> From: t.petch To: Sean Turner References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> <89AE2EA7-BF74-4A59-9C6C-9F50595458D8@sn3rd.com> Date: Tue, 2 Aug 2016 17:32:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [31.50.86.164] X-ClientProxiedBy: HE1PR0401CA0026.eurprd04.prod.outlook.com (10.166.116.164) To DB5PR07MB1624.eurprd07.prod.outlook.com (10.166.12.151) X-MS-Office365-Filtering-Correlation-Id: 0b63546f-9139-4e27-9a3a-08d3baf30cdf X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1624; 2:h7rf8uIfNj2R+766gJDmlL3X+zi5N6NZs5Wur7wiM9B43Wim0S0q5b41UCw7QFwOBk/tA+sI0H+R4FvnHwwCYJLDeJsWFyLBPUAsTjYfhFAbqmMK4GRuFzyqTUsxsL2ACutS7n/DbL/8TNA0HsExWfjA+fm1yaGNt86vJf/6vhGkszi6VDID99gV9USP8ukj; 3:cyr9ICglMiAjutKT4I0XyPY3pjG37HhUhIZlaJu/nW2eFzQPWmLEwpA/XD2GWVPKiWwm9eQy8dYBooqSxqFL25W6okLfHF7iKcO3OSoDNPbaKtpOwDccn1tl9w8u8ViI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1624; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1624; 25:75lQDhQoBYODyAUm55vnF/tqEeTx9Ti1mqVjlNIrG0SRPGFULDuFQfGhlavahHXDJmcZxhIyFLf0cGI7pxHeh9Kqak41JlPd8eEAguGZyiv4ZtQluZyeZjQIH0MKbgxyJJo8XbPiZg0je5KrfFMgqoAHdDD2F6KnmGDd06Q4ts0nQXEwCrW33kYYwZO/NzXjbDUt5jc6zxbLgMgPY39EP1c52PWW0nHdZSKMK6awpS4vUt+C8Lyu8yoHG4BCCUozMBiOF/HqkwgldcrLAPAe8LNS3OTa23Jk0Wzsm3wpW0HMYnDa15MwJKhcPczr+xgEeTLVksyz++ljpSEF4o4qNviDWoI+NnM2mpr7DHJQV9zYZEOmk6Scsm5TqmvXx0v/ziveFB4/GXqElQqGDP7LSudv3/MI7RR50v5Najgu/mN1PfVrsGqP+R3xTnZBU1D7f9W6lBY4sQeqbvyBU6w1UmNeXsURp5Ek1PZHpW7EsuXD7df5bCySbpWFU6fPtRcoKKi/Ysvk17P3YhQ2m5EfFqBr6y8XZzW2illjxBqNBsKigBf1KBOJsJnfAMxJ01pqILbJk+33Jyt/HX+z3gdn3IfgwdC+cTJdN6IJBVgerTbQrQhClropjGpi+JlqWYCzhiNpKYElYd+aCSgANWAXKE/6jLEsnldT4WIAanhMSBbM9KYTKZPCyzARH2Rk+wSaHEdpHF4qGrlHv9rZNHsNuOHwfLvjdgCTutrrjal+52Rmy3gVOiPysZz5k0f8HJN22mEke3aQlboodPgQGSywVFVG+tK/SOGcCSe1qfc0sPsaWDIVomCvEzA1XOrqjjEokeEkyvY+pdwCOOOMMU9jqA== X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1624; 31:EagzNvhleTYeJEBMYlBlLkcmcrOWlt24PsqwhJS+4XirYBwjmRFEj71OaA8ecqYwMdAJNwrL/HgwoblzgdQFpdCZzxM+4P9jAddJzQB19gcBmwre6E4S0yeWWr5h3Bv227Ar4XEDkP9CdMiR6lnyO4qK0lyNI5adUcy2lvw2r/M8KmosaYHcAYLC5wRANcETBQIuJyWhrYrF7Rzsfq+RI1hYtDhLPXKARAI2aH32jUI=; 4:PDFWFVbdgnHhj7eoPA/wGE7YEU8XvY8ZjFhmhkolc8AbvTWJzWHqzAHk9owskXwGLbnmgh7aS/0YrPyhDCjxdXPfIhFNoLF/alIEG4Buy9XVcLWvKMnJcAns2u9cLKueMlI4XAif69Z+P5UJ80DElLxO+cqbHbDlWiFBFVUWfanBPtQevePHzoO18RBitFoOARRX1KQ/GVxrxc9m+dp4aSsn1Fl7zO0GoGjLlAfGDiMmDmcbtXvM0QH2qyBxX78+09HrAPpy4HfKSBMnj86zYkU6nan6YHIOeLcNRx28PS+TqCNpbJfQogcsTdcvKYZ2GCnf93nsTrT5UcFTnvnYEg4WlqR6+blW4BKoj6C8UYj8TLA+QmBXQD7FpQY3GPFhSVRjI+ugmHQaAXK6Vg94ds7MycI0gMsQKuYo27k9XjiFqV7v7K2EBwzLbOum50/XYhvjAISOVgtNwsQj5bKVMrqoqzlg4W0eGzo+fqR7sJo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705)(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1624; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1624; X-Forefront-PRVS: 0022134A87 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(377454003)(199003)(24454002)(13464003)(189002)(51444003)(42186005)(1456003)(61296003)(33646002)(93886004)(84392002)(77096005)(14496001)(116806002)(106356001)(86362001)(105586002)(15975445007)(92566002)(1556002)(44736004)(62236002)(81816999)(50986999)(44716002)(6116002)(101416001)(66066001)(50466002)(7846002)(110136002)(189998001)(3846002)(23676002)(81166006)(8676002)(68736007)(345774005)(47776003)(81156014)(81686999)(76176999)(19580405001)(9686002)(2870700001)(4326007)(97736004)(19580395003)(586003)(305945005)(50226002)(7736002)(2906002)(74416001)(7726001)(4720700001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1624; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjI0OzIzOjJzTkQ0RlVMaGxCbGxKYm5ENXhkQTQyV09w?= =?utf-8?B?STdUclp1S0NSVm9HaVlwQlMxQ09XaTZXOWthaHp0M3MzTU1QU1VkdkhwY1R6?= =?utf-8?B?RzQ0L2ZlUkJ0c0FXaHUwdmZuVTFXTW53NWdSblNJbkQrQ3gvZUY0VHc5SmRR?= =?utf-8?B?RTlGd3VsdytVNHZMODJYSXpWZmxTcCtnOUN2SUlyRU10WWZnMDJxQXFWbyta?= =?utf-8?B?TEoyUHhhYWFsb0RuNkxpaHJWK2JFKzNocG92ODROYUlaZStWT3RYSy9CallS?= =?utf-8?B?eGlnM3U4RXBxVHVhYUlwY2hqZnR6SVNLL2d2cGsyeU5Yb05sc2t6dm5KNm9R?= =?utf-8?B?bE1VRXM1RHNPeVgvSFE2a21iMlZ5UUlwcm5QVkMvZ1RFWlVUZzhObStlQ2ZG?= =?utf-8?B?Qkx6UDRTQWs5MlgyNlNJcGNVMmt6aldPcVRWdmh2L2RHYUxZNElHZFJyS1JD?= =?utf-8?B?TFh6Q05ENFRVSkxGNnR6K3JmaE0yREhHeTl6Vjl5RmRVVlhKNkV2N1A5U3dN?= =?utf-8?B?Znk3R3Y2L0kwbkU4U0JMZDBxQ0tZQ1dVNnFvWHo0bnNGS3pQcWRic1FmRlo2?= =?utf-8?B?eVNSM3dOdFQwWlpLSkRWS3NCOXFGQVA1Vm1EYjYzQ0JyZWw2SktwQzZQL1RQ?= =?utf-8?B?a2FOemJNbEczOXhVTitTWHNJNHJXSi9Yakd2TXNxN2NrT3c3ZzFWeUFwTnhT?= =?utf-8?B?dkJRTng3bnNVR3VuU2M0YU5QV01MZEpWZkMrQU12N3hoZzBJak43M1IzR1hE?= =?utf-8?B?VWdKZG5Ba2dHV3BYRXl0YXRobHUzZVJlVjUzRGlxUittNjk3SytmRXhxZlhH?= =?utf-8?B?RUhDU3owQlVob1UxMlJCN2ltWVdnd0NpSmY3aklwalphblNhTDFOdzNOUkxh?= =?utf-8?B?dis0eXNYSUt1a3Q4UzRTRXFWZ2RQRG5sVUk4V1A2ejJkcDhYOVFjUTVER051?= =?utf-8?B?aHlEd1RaU2FhRnlhRkQzQjRFMDliWFV6ODVRQ2t2eG4rWE9lN1h6eTZvSW16?= =?utf-8?B?WmNDYXFBK2YvcHpMcEtsQTl5VnB4ekhuV00wbDBFeDAxd0VzMjNtTGlVWmE4?= =?utf-8?B?eThXQlh2eVRob2VRaVJaQldyVGpBckxVNXhZcWhsanNvNDR0YVRLK3UzVEFK?= =?utf-8?B?cWtzUVRxQ2U4RU1VVjNwZEYwV08yK05seHVScFBKSjM5Uk5DcHhaSmMzVnFj?= =?utf-8?B?STlQZ3JvWldnWGErY2syTHlZeU1zdTF6eS9wVVBvVjB1U1dUU3crZ0YvcVlV?= =?utf-8?B?SWJVOS9Vb3dBR0YvNUZjZmp6TnBFSFhNL3gvYmtmZG5BTytBQndlMWo3cWEw?= =?utf-8?B?ckFrUUUvWXJHNWhpaGxjY3drR0tXNVFCTy9xVGRRTWJ6YlRGbDhiWDB5b3FB?= =?utf-8?B?SUFuc09ZMnVzRlR0Ni9qUDZNdXFraWhXaWwxbUI0SGxmelRvNjZUdGlpaTRO?= =?utf-8?B?U1dQa1pyYkdNdC9ISU5zT0ovM0VneWx2NWZieXYzaDU0S0x5QXZRSUZueEEv?= =?utf-8?B?WldZbmRDN2NBOGhlK3lGUmdrdnFsZ0JMK1BIRDU5TmJhWGJrZTlpUlFGOHo0?= =?utf-8?B?c1NDUkRiYmRncDk1SklhVW1GbEpNcWg5cVY0bEhHdCtqNFpoQkFrdDlERHJi?= =?utf-8?B?WUJmQyttSUI3QzBqOGhOSnM5U0NBd3dKZE9hVXJMZWtSNHpvSWdxME9jQThi?= =?utf-8?B?cjczQVVJY3JtSlIyYlZUWFhmcDJKTVVDUURKcUVtR1pjM3IvTVdEN3pHeTNw?= =?utf-8?B?d3JFbWFyS2NOU3h6TENlOVU2RTJQeC9VYkpLTUNQeXZ6SnBjWXBIQ053djdx?= =?utf-8?B?VFJYVEd5S1p0cnNLUWNZSDFwUnpLZ2xDSTVPbGxuUm94Yy9lbEkyNm1mcDRS?= =?utf-8?B?U3A4d2pSTlh3R0xpZ1Mzbmc0SHV4VDZUMENtTFd5a1lxWHJsY243YTdFU3o2?= =?utf-8?B?MVBOd2d3Ykl1UXhMczlZcUVJSHJnMTZ2Q1JzOXo3VGUxWFZKT1dmeVZEQWFq?= =?utf-8?Q?YEtQSd?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1624; 6:pJk6GAqERcZ4Xt7lv7TBn0OYezOIbXBADNgaRDBYhLxYikuIsVaF4HuwVKtUY7xhcnEFj79GdFNcBMv5KQnTBriapdFJVleisIndJ2v5V0zsa5ybE7+vZzjPLUlvcMNr0/64t1t6UYBxnh6NDoDYmextxlx5PiR+woq/Gjb8meGDuKg7bBrChg+afZxZq2AySWNUxCd4LQ2jA2pDJjeDvqLmXaH6nT7XWdxwyEnS1pA/GDvMcn5lwmQN1gtP9UMA5DcecVOed8L2zcHbT8WBg0ZGLmgC7B1l14dgSRv0w1g=; 5:7Z6sWlA4jC3M6ShGRhB7OG89eMoKr9sArBqur6SNiRorpo7Cr68TCyh1gAdpLBkcGaN0+lSAT36qHDhoho5IKgh8ZwEcMYR4z1f3CfodXVo2Ap6uIGtghXHBh7ZabO4jBXQVi8EVq3moiOZ4gACyuQ==; 24:1DRO/4YKYHi75cLAZ4Fj2q67uKL3L119nWeGm1ab/P5FdQkB7si7JBMNDPDbi9DW9J973rEMA3GyNW+QJLN+DK5yjiSYQEwBJkihYrOx68Q=; 7:TWBFgZwul595lXwEQeSkm5GxH6PVe1oN473bj0kBTOnOBXDWZBoVvZ+XNfeemltEZVfk1KgbVNYjBAIUtghRixyQ1zpVBQVJ2i4YV3quXPyY+SRZqMbkKvFfmpuApMyXBjrRFaM0o4H0Pkumj+jlp1rkGezghOtLAA2j+QgI2CuKJNzyg6X0LMnNXtzsElO5GDBkzOhDndQuvqfH2MAZlvMQFmYfXfQRuM7AtEUm+6c/Vnu7o46yH4HShZuLI6X0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 16:35:43.8345 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1624 Archived-At: Cc: Rob Austein , IETF SIDR Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:35:53 -0000 ----- Original Message ----- From: "Sean Turner" To: "t.petch" Cc: "Rob Austein" ; "IETF SIDR" Sent: Tuesday, August 02, 2016 2:20 PM On Aug 02, 2016, at 05:30, t.petch wrote: > > Sean > > I am a fan of giving IANA as little a need to think as possible so would > prefer the IANA considerations to be more expansive. With three > registries being updated, I would like to see three paragraphs and, with > five numbers, would like to see TBD1 to TBD5, not TBD times five, e.g. I guess I’m not as paranoid as you, but #ing the TBDs would definitely make it clearer to IANA and the RFC where the values are supposed to go. If “TBD1" is replaces the “TBD" in the 6484 updates section then the 2 & 3 are the modules and 4 and 5 are the extensions. Revised modules follow what I think you’re asking for wrt the IANA considerations section: Sean Yes, I am paranoid and yes, this looks good to my eyes, Tom Petch #.# IANA Considerations IANA is to add the following to the SMI Security for PKIX Certificate Policies registry: Decimal Description References TBD1 id-cp-ipAddr-asNumber-v2 [this RFC] IANA is to add the following to the SMI Security for PKIX Module Identifier registry: Decimal Description References TBD2 IPAddrAndASCertExtn-v2 [this RFC] TBD3 IPAddrAndASCertExtn-2010v2 [this RFC] IANA is to add the following to the SMI Security for PKIX Certificate Extension registry: Decimal Description References TBD4 id-pe-ipAddrBlocks-v2 [this RFC] TBD5 id-pe-autonomousSysIds-v2 [this RFC] #.# ’88 ASN.1 Module IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-v2(TBD2) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS -- PKIX specific OIDs and arcs -- id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) } ; -- Validation Reconsidered IP Address Delegation Extension OID -- id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD4 } -- Validation Reconsidered IP Address Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- -- Validation Reconsidered Autonomous System Identifier Delegation Extension OID -- id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD5 } -- Validation Reconsidered Autonomous System Identifier Delegation Extension Syntax -- -- Syntax is imported from [RFC3779] -- END #.# ’08 ASN.1 Module IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2v2(TBD3) } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS -- PKIX specific OIDs and arcs — id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} -- IP Address Block and AS Identifiers Syntax -- IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn-2010 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident-2(72) } ; -- -- Extensions contains the set of extensions defined in this -- module -- -- These are intended to be placed in public key certificates -- and thus should be added to the CertExtensions extension -- set in PKIXImplicit-2009 defined for [RFC5280] -- Extensions EXTENSION ::= { ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 } -- Validation Reconsidered IP Address Delegation Extension OID — ext-pe-ipAddrBlocks-v2 EXTENSION ::= { SYNTAX IPAddrBlocks IDENTIFIED BY id-pe-ipAddrBlocks-v2 } id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD4 } -- IP Address Delegation Extension Syntax — -- Syntax is imported from [RFC6268] — -- Validation Reconsidered Autonomous System Identifier Delegation Extension OID — ext-pe-autonomousSysIds-v2 EXTENSION ::= { SYNTAX ASIdentifiers IDENTIFIED BY id-pe-autonomousSysIds-v2 } id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD5 } -- Validation Reconsidered Autonomous System Identifier Delegation Extension Syntax -- -- Syntax is imported from [RFC6268] -- END > ----- Original Message ----- > From: "Sean Turner" > To: "Rob Austein" ; "Tim Bruijnzeels" ; > "Russ Housley" > Cc: "IETF SIDR" > Sent: Tuesday, August 02, 2016 12:28 AM > >> On Jul 21, 2016, at 06:36, Tim Bruijnzeels wrote: >> >> Hi Russ, >> >> Thank you for the pointers. I am traveling now but I will get back to > it. >> >> Thanks >> Tim >> >>> On 21 Jul 2016, at 10:56, Russ Housley wrote: >>> >>> >>> On Jul 19, 2016, at 9:14 AM, Rob Austein wrote: >>> >>>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote: >>>>> >>>>> Does this apply to the Certificate Policy OID too? If memory is >>>>> correct, the current CP has a normative pinter to RFC 3779. >>>> >>>> Good catch. >>>> >>>> Not sure a policy OID change is necessary, although might be > simplest. >>>> If there's a reference, we either need to change the OID or change > the >>>> definition of what the OID means. >>>> >>>> IIRC, the OpenSSL library code doesn't do anything RFC-3779-specific >>>> for the policy OID, it just follows the usual rules; it's the RP > code >>>> built on top of the library that demands that particular policy OID. >>>> So at least in the OpenSSL case, changing the policy OID may not > have >>>> any noticeable effect on correctness of software behavior. >>> >>> During the SIDR session today, there seemed to be some confusion > about which OIDs we are taking about. >>> >>> The first two are from RFC 3779. They appear here in the IANA > registry: >>> > http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number > s-1.3.6.1.5.5.7.1 >>> >>> The two OIDs are: >>> 1.3.6.1.5.5.7.1.7 id-pe-ipAddrBlocks >>> 1.3.6.1.5.5.7.1.8 id-pe-autonomousSysIds >>> >>> In addition, RFC 6484 assigned an OID for the certificate policy. It > appears here in the IANA registry: >>> > http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number > s-1.3.6.1.5.5.7.14 >>> >>> The OID is: >>> 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber >>> >>> I think this is a very good candidate for early IANA code point > allocation. I think that our AD can assist with that. >>> >>> Russ > > To make sure I’m following along, to address the "Updates: 3779, 6484, > 6487 (if approved)" changes would the follow changes work: > > 0) RFC6484-related changes > > If we’re going with two OIDs (one for the original “strict" validation > and one for new “relaxed” validation), then I’m hoping that we can just > define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I hope > we don’t also have to update s4.1.1, s4.5.1, and s4.7.1 where RFC 3779 > is mentioned). Here’s some text for a new section: > > #.# Updates to RFC 6484 > > This section replaces s1.2 of [RFC6484] with the following: > > The name of this document is "Certificate Policy (CP) for the Resource > PKI (RPKI)”. > > This policy has been assigned the following two OIDs: > > id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) cp(14) 2 } > > id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) cp(14) TBD } > > id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] indicate > that the original certification path validation rules are to be used. > id-cp-ipAddr-asNumber-v2 and the extensions defined in [this document] > indicate that the validation reconsidered certification path validation > rules defined in [this document] are to be used. > > > 1) IANA registrations > > We need to register some OIDs with IANA. Here’s an IANA considerations > section (assumes we’re registering a new CP OID - [] references will be > to whatever section # it ends up being): > > 6. IANA Considerations > > IANA is to register the following five OIDs: > > - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI > Security for PKIX Certificate Policies registry. > > - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert > Section and #] in the SMI Security for PKIX Certificate Extension > registry. > > - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert > Section and #] in the SMI Security for PKIX Module Identifier registry. > > RFC EDITOR: There are two ASN.1 modules both include the same > assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2, > i.e., the assignments are made by IANA once and the values are included > in the two modules. Please delete this prior to publication. > > > 2) RFC3799-related changes > > As far as RFC 3779 updates go, we probably need to update s2.3 and s3.3 > as well as add new ASN.1 modules. > > > 2.1) I haven’t got text off the top of my head for the s2.3 and s3.3 > changes. > > > 2.2) As far as the ASN.1-related changes go here’s two ASN.1 module(s). > The modules define the new OIDs and imports the syntax from > RFC3779/RFC6268. The basic idea is to keep the modules as short as > possible. The 2nd module is for the ’08 ASN.1 that was defined in RFC > 6268 to be used with RFC5911/5912. > > #.# ’88 ASN.1 Module > > IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-v2(TBD) } > > DEFINITIONS EXPLICIT TAGS ::= > > BEGIN > > -- EXPORTS ALL -- > > IMPORTS > > -- PKIX specific OIDs and arcs -- > > id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } > > -- IP Address Block and AS Identifiers Syntax -- > > IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) > identified-organization(3) dod(6) internet(1) security(5) > mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident(30) } > ; > > -- Validation Reconsidered IP Address Delegation Extension OID -- > > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD } > > -- Validation Reconsidered IP Address Delegation Extension Syntax -- > -- Syntax is imported from [RFC3779] -- > > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension OID -- > > id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe TBD } > > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC3779] -- > > END > > > #.# ’08 ASN.1 Module > > IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2v2(TBD) } > > DEFINITIONS EXPLICIT TAGS ::= > > BEGIN > > EXPORTS ALL; > IMPORTS > > -- PKIX specific OIDs and arcs — > > id-pe > FROM PKIX1Explicit-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkix1-explicit-02(51)} > > EXTENSION > FROM PKIX-CommonTypes-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkixCommon-02(57)} > > -- IP Address Block and AS Identifiers Syntax -- > > IPAddrBlocks, ASIdentifiers > FROM IPAddrAndASCertExtn-2010 > { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2(72) } > ; > > -- > -- Extensions contains the set of extensions defined in this > -- module > -- > -- These are intended to be placed in public key certificates > -- and thus should be added to the CertExtensions extension > -- set in PKIXImplicit-2009 defined for [RFC5280 > ] > -- > > Extensions EXTENSION ::= { > ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 > } > > -- Validation Reconsidered IP Address Delegation Extension OID — > > ext-pe-ipAddrBlocks-v2 EXTENSION ::= { > SYNTAX IPAddrBlocks > IDENTIFIED BY id-pe-ipAddrBlocks-v2 > } > > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe TBD } > > -- IP Address Delegation Extension Syntax — > -- Syntax is imported from [RFC6268] — > > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension OID — > > ext-pe-autonomousSysIds-v2 EXTENSION ::= { > SYNTAX ASIdentifiers > IDENTIFIED BY id-pe-autonomousSysIds-v2 > } > > id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe TBD } > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC6268] -- > > END > > 2.3) If we want to be really ambitious, then right after the ASN.1 > modules are included in the draft we could request the WG chairs start > an early IANA allocation request for these OID ;) > > Cheers, > > spt > > > > > ---------------------------------------------------------------------- -- > -------- > > >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > From nobody Tue Aug 2 12:54:16 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1CB12D8ED for ; Tue, 2 Aug 2016 12:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61CpRGw9BeUN for ; Tue, 2 Aug 2016 12:54:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626BE12D913 for ; Tue, 2 Aug 2016 12:54:08 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:35797 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bUflK-000Hyv-99; Tue, 02 Aug 2016 15:54:02 -0400 From: Stephen Kent To: Randy Bush References: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com> <227BF007-90BD-4301-A349-FC01A1A5969A@ripe.net> <9b33dd4f-6361-626d-5e0b-fa6d4ba3b260@bbn.com> Message-ID: Date: Tue, 2 Aug 2016 15:54:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr Subject: Re: [sidr] adverse actions -01 posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:54:15 -0000 Randy >>>> Tim offered no suggestion for a different term, which is not helpful. >>> the suggestion was "unwanted". >> I reread Tim's message; I don't interpret it as having suggested >> "unwanted" as an alternative. > that is clear. others, such as matthias and i, did. but this is not > productive. > > to be clear, i hereby suggest s/adverse/unwanted/ I will process your suggestion in the same spirit that you continue to ignore my comments about revising the folksy language in the LTA use cases document. The term "adverse" is appropriate here. Contrary to Tim's assertion, it does not imply, ".. that for conscious actions by a parent CA against the will by a child CA, the parent is "wrong" and the child is "right." "unwanted" is a wimpy term that fails to convey the fact that the actions have a negative impact on the INR holder. Steve From nobody Tue Aug 2 20:00:51 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB112D621 for ; Tue, 2 Aug 2016 20:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZPopZ7R7D-x for ; Tue, 2 Aug 2016 20:00:48 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D729E12D1B2 for ; Tue, 2 Aug 2016 20:00:47 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id v123so60099131qkh.3 for ; Tue, 02 Aug 2016 20:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nAAof6Oiz9hWXLfaxj1odPDPPbGk/3a94iWKev53zdg=; b=Nx34Ibh1LLD0Es7CDW2d0yqIm2ddMh3aw+amYPKZ+tfTcxKy2IsIz3jGYUgPLI2JkU AY1pD94Q2aGdxtYp9yAby1XH4Iny1biMtHWxqv45j8taHTmkB1lqZzOGn3Zs4kjatQtz kgHkFrd7YwtdSs03HbcnUtR7AgZRd2+ys/0bu5TQT0z8qwlMDB8v4N3+8hl43I/Ag50n m/sPMQ4PIAsKJtVQsAaxk/oiToW7myoPSZigmcajyGFpvrf86JUew2qLw+bbVmEyG2Cl OZeM5+gKuDN2HGPLqfPJXcBWPKM0Hxd/URgJI/8ejRPzRRWGdESjmbyyAz+LhCdnKZCU K1Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nAAof6Oiz9hWXLfaxj1odPDPPbGk/3a94iWKev53zdg=; b=H91BPGY7v272vLW1QYHbZGL9/SatIfJiOTld2q+nxRhRiYfLbqPInsruJ/ZR9+22Sr w6OWC3myZSi0XrzEoG107lzaUQfKpM1MUwQgs69MYg6ppDJtNdmP731r/jiu9Mvw6ScZ HEZqWneDJTKY5SfUbUbBvJ2DlV7oyg6whlypzAWKL4bcXsqVVn2h7xBktrHbqQEga3jK +TyxxKPtjYUUpPS+MiAoLOY+3+9X+++OkKWy4zIv+2gvRgMJ/dmoVS7NQrXmUqBKs9LM dMCTis1Sq9Q/OTwvyreaM+K0eXcuI+qG1pTl8cAFmOjuNcDJw/Km5wBBR1RSjUoVzvNc JywA== X-Gm-Message-State: AEkoout9/uQ5Km1CUsHgfwYctoysQp3P9EegtLG9jqcLFlTlt+EekSLM7LjRRxYw1tBBOplzDLg7TwKFzWxLHA== X-Received: by 10.55.78.213 with SMTP id c204mr14902416qkb.48.1470193246909; Tue, 02 Aug 2016 20:00:46 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 2 Aug 2016 20:00:46 -0700 (PDT) In-Reply-To: References: <20160321224131.12255.6798.idtracker@ietfa.amsl.com> <20160321224428.AB8BF3DF33E2@minas-ithil.hactrn.net> From: Christopher Morrow Date: Tue, 2 Aug 2016 23:00:46 -0400 X-Google-Sender-Auth: ynmvxCG5rENPpDgtH3PODLMsOkU Message-ID: To: Samuel Weiler Content-Type: multipart/alternative; boundary=001a11488c783bbca90539220aa6 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:00:50 -0000 --001a11488c783bbca90539220aa6 Content-Type: text/plain; charset=UTF-8 Ok, since we have cycled this document a few times and the last set(s) of comments were dealt with, I'm going to send a WGLC note, let's get chatty on that thread? On Mon, Mar 28, 2016 at 1:12 PM, Samuel Weiler wrote: > On Mon, 21 Mar 2016, Rob Austein wrote: > > Protocol simplification (!) per discussion with Oleg. >> > > The changes in -08 are based on Oleg's astute observations that: > > -- per-PDU success messages aren't really helpful, especially if every > update is tagged, and > > -- interleaving the list command with changes could be ambiguous and > probably isn't useful. > > > Full list of changes: > > -- a single success message replaces per-PDU success responses > -- tag is now mandatory on publish/withdraw > -- list command must standalone; cannot be combined with changes > -- no tag on the list command, since it can't be combined > -- added an error code for XML errors > -- incremented the protocol version number > -- some rearrangement of text > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a11488c783bbca90539220aa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, since we have cycled this document a few times and the= last set(s) of comments were dealt with, I'm going to send a WGLC note= , let's get chatty on that thread?

=
On Mon, Mar 28, 2016 at 1:12 PM, Samuel Weiler <= span dir=3D"ltr"><weiler@tislabs.com> wrote:
On Mon, 21 Mar 2016, Rob Austein wrote:

Protocol simplification (!) per discussion with Oleg.

The changes in -08 are based on Oleg's astute observations that:

-- per-PDU success messages aren't really helpful, especially if every = update is tagged, and

-- interleaving the list command with changes could be ambiguous and probab= ly isn't useful.


Full list of changes:

-- a single success message replaces per-PDU success responses
-- tag is now mandatory on publish/withdraw
-- list command must standalone; cannot be combined with changes
-- no tag on the list command, since it can't be combined
-- added an error code for XML errors
-- incremented the protocol version number
-- some rearrangement of text


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

--001a11488c783bbca90539220aa6-- From nobody Tue Aug 2 20:05:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC22F12D63A; Tue, 2 Aug 2016 20:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZdHCFOGaKYC; Tue, 2 Aug 2016 20:05:06 -0700 (PDT) Received: from relay.kvm02.ops-netman.net (relay.kvm02.ops-netman.net [IPv6:2606:700:e:550:5c82:28ff:fe25:4960]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002EC12D670; Tue, 2 Aug 2016 20:05:05 -0700 (PDT) Received: from mail.ops-netman.net (unknown [208.76.12.119]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relay.kvm02.ops-netman.net (Postfix) with ESMTPS id 785AE40906; Wed, 3 Aug 2016 03:05:03 +0000 (UTC) Received: from morrowc-glaptop4.roam.corp.google.com.ops-netman.net (static-96-241-182-39.washdc.fios.verizon.net [96.241.182.39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.ops-netman.net (Postfix) with ESMTPSA id 6246E151B6D8; Wed, 3 Aug 2016 03:05:03 +0000 (UTC) Date: Tue, 02 Aug 2016 23:05:03 -0400 Message-ID: From: Chris Morrow To: sidr@ietf.org, sidr-chairs@ietf.org,sidr-ads@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) Organization: Operations Network Management, Ltd. MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:05:08 -0000 Good morning (european folks): This starts the 2 week (14 days or 336 hr) WGLC for: https://tools.ietf.org/html/draft-ietf-sidr-publication-08 Abstract content: "This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so." The document has made eight, at least, revisions in the WG discussion space, all comments are dealt with and it appears to be ready to ascend to the next tier of existence. Please give it a read through, and provide comments/direction in this thread. Thanks! -chris co-chair From nobody Wed Aug 3 11:32:23 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEF112D1B9 for ; Wed, 3 Aug 2016 11:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gox64vfMtnFI for ; Wed, 3 Aug 2016 11:32:19 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6E012D0B4 for ; Wed, 3 Aug 2016 11:32:18 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bV0xg-000CZ1-NO; Wed, 03 Aug 2016 20:32:15 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-11.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bV0xg-0002CK-FT; Wed, 03 Aug 2016 20:32:12 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels X-Priority: 3 In-Reply-To: <00c201d1ecdb$8d45a640$4001a8c0@gateway.2wire.net> Date: Wed, 3 Aug 2016 20:32:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69C24BE0-A64B-4E62-B2AE-50B710A6CD7E@ripe.net> References: <20160719111830.12A97412B25E@minas-ithil.hactrn.net> <20160719131456.D0705412C916@minas-ithil.hactrn.net> <173EB2A5-1F28-4108-9D91-B3D1C2B3126C@ripe.net> <2F66A19D-8ADD-496A-A1A6-61D8277DAF4C@sn3rd.com> <00c501d1eca0$8fd24660$4001a8c0@gateway.2wire.net> <89AE2EA7-BF74-4A59-9C6C-9F50595458D8@sn3rd.com> <00c201d1ecdb$8d45a640$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ---------- X-RIPE-Spam-Report: Spam Total Points: -10.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190d84f72e4ec2e022a7533ed1ee5915e2 Archived-At: Cc: Rob Austein , IETF SIDR Subject: Re: [sidr] Validation reconsidered and X.509v3 extension OIDs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 18:32:22 -0000 Hi all, Just a quick sign of life on this.. Other work intervened but I haven't forgotten. Suggestion are very much = appreciated! I hope to edit a new version in the coming weeks. Tim > On 02 Aug 2016, at 18:32, t.petch wrote: >=20 > ----- Original Message ----- > From: "Sean Turner" > To: "t.petch" > Cc: "Rob Austein" ; "IETF SIDR" > Sent: Tuesday, August 02, 2016 2:20 PM > On Aug 02, 2016, at 05:30, t.petch wrote: >>=20 >> Sean >>=20 >> I am a fan of giving IANA as little a need to think as possible so > would >> prefer the IANA considerations to be more expansive. With three >> registries being updated, I would like to see three paragraphs and, > with >> five numbers, would like to see TBD1 to TBD5, not TBD times five, = e.g. >=20 > I guess I=E2=80=99m not as paranoid as you, but #ing the TBDs would = definitely > make it clearer to IANA and the RFC where the values are supposed to = go. >=20 > If =E2=80=9CTBD1" is replaces the =E2=80=9CTBD" in the 6484 updates = section then the 2 & > 3 are the modules and 4 and 5 are the extensions. Revised modules > follow what I think you=E2=80=99re asking for wrt the IANA = considerations > section: >=20 > >=20 > Sean >=20 > Yes, I am paranoid and yes, this looks good to my eyes, >=20 > Tom Petch >=20 > #.# IANA Considerations >=20 > IANA is to add the following to the SMI Security for PKIX Certificate > Policies registry: >=20 > Decimal Description References >=20 > TBD1 id-cp-ipAddr-asNumber-v2 [this RFC] >=20 > IANA is to add the following to the SMI Security for PKIX Module > Identifier registry: >=20 > Decimal Description References >=20 > TBD2 IPAddrAndASCertExtn-v2 [this RFC] > TBD3 IPAddrAndASCertExtn-2010v2 [this RFC] >=20 > IANA is to add the following to the SMI Security for PKIX Certificate > Extension registry: >=20 > Decimal Description References >=20 > TBD4 id-pe-ipAddrBlocks-v2 [this RFC] > TBD5 id-pe-autonomousSysIds-v2 [this RFC] >=20 > #.# =E2=80=9988 ASN.1 Module >=20 > IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-v2(TBD2) } >=20 > DEFINITIONS EXPLICIT TAGS ::=3D >=20 > BEGIN >=20 > -- EXPORTS ALL -- >=20 > IMPORTS >=20 > -- PKIX specific OIDs and arcs -- >=20 > id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } >=20 > -- IP Address Block and AS Identifiers Syntax -- >=20 > IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) > identified-organization(3) dod(6) internet(1) security(5) > mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident(30) } > ; >=20 > -- Validation Reconsidered IP Address Delegation Extension OID -- >=20 > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD4 } >=20 > -- Validation Reconsidered IP Address Delegation Extension Syntax -- > -- Syntax is imported from [RFC3779] -- >=20 > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension OID -- >=20 > id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD5 } >=20 > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC3779] -- >=20 > END >=20 >=20 > #.# =E2=80=9908 ASN.1 Module >=20 > IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2v2(TBD3) } >=20 > DEFINITIONS EXPLICIT TAGS ::=3D >=20 > BEGIN >=20 > EXPORTS ALL; > IMPORTS >=20 > -- PKIX specific OIDs and arcs =E2=80=94 >=20 > id-pe > FROM PKIX1Explicit-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkix1-explicit-02(51)} >=20 > EXTENSION > FROM PKIX-CommonTypes-2009 > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-pkixCommon-02(57)} >=20 > -- IP Address Block and AS Identifiers Syntax -- >=20 > IPAddrBlocks, ASIdentifiers > FROM IPAddrAndASCertExtn-2010 > { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) mod(0) > id-mod-ip-addr-and-as-ident-2(72) } > ; >=20 > -- > -- Extensions contains the set of extensions defined in this > -- module > -- > -- These are intended to be placed in public key certificates > -- and thus should be added to the CertExtensions extension > -- set in PKIXImplicit-2009 defined for [RFC5280] > -- >=20 > Extensions EXTENSION ::=3D { > ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 > } >=20 > -- Validation Reconsidered IP Address Delegation Extension OID = =E2=80=94 >=20 > ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D { > SYNTAX IPAddrBlocks > IDENTIFIED BY id-pe-ipAddrBlocks-v2 > } >=20 > id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD4 } >=20 > -- IP Address Delegation Extension Syntax =E2=80=94 > -- Syntax is imported from [RFC6268] =E2=80=94 >=20 > -- Validation Reconsidered Autonomous System Identifier = Delegation > Extension OID =E2=80=94 >=20 > ext-pe-autonomousSysIds-v2 EXTENSION ::=3D { > SYNTAX ASIdentifiers > IDENTIFIED BY id-pe-autonomousSysIds-v2 > } >=20 > id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD5 } >=20 > -- Validation Reconsidered Autonomous System Identifier Delegation > Extension Syntax -- > -- Syntax is imported from [RFC6268] -- >=20 > END >=20 >=20 >> ----- Original Message ----- >> From: "Sean Turner" >> To: "Rob Austein" ; "Tim Bruijnzeels" ; >> "Russ Housley" >> Cc: "IETF SIDR" >> Sent: Tuesday, August 02, 2016 12:28 AM >>=20 >>> On Jul 21, 2016, at 06:36, Tim Bruijnzeels wrote: >>>=20 >>> Hi Russ, >>>=20 >>> Thank you for the pointers. I am traveling now but I will get back = to >> it. >>>=20 >>> Thanks >>> Tim >>>=20 >>>> On 21 Jul 2016, at 10:56, Russ Housley = wrote: >>>>=20 >>>>=20 >>>> On Jul 19, 2016, at 9:14 AM, Rob Austein wrote: >>>>=20 >>>>> At Tue, 19 Jul 2016 08:43:00 -0400, Russ Housley wrote: >>>>>>=20 >>>>>> Does this apply to the Certificate Policy OID too? If memory is >>>>>> correct, the current CP has a normative pinter to RFC 3779. >>>>>=20 >>>>> Good catch. >>>>>=20 >>>>> Not sure a policy OID change is necessary, although might be >> simplest. >>>>> If there's a reference, we either need to change the OID or change >> the >>>>> definition of what the OID means. >>>>>=20 >>>>> IIRC, the OpenSSL library code doesn't do anything > RFC-3779-specific >>>>> for the policy OID, it just follows the usual rules; it's the RP >> code >>>>> built on top of the library that demands that particular policy > OID. >>>>> So at least in the OpenSSL case, changing the policy OID may not >> have >>>>> any noticeable effect on correctness of software behavior. >>>>=20 >>>> During the SIDR session today, there seemed to be some confusion >> about which OIDs we are taking about. >>>>=20 >>>> The first two are from RFC 3779. They appear here in the IANA >> registry: >>>>=20 >>=20 > = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number >> s-1.3.6.1.5.5.7.1 >>>>=20 >>>> The two OIDs are: >>>> 1.3.6.1.5.5.7.1.7 id-pe-ipAddrBlocks >>>> 1.3.6.1.5.5.7.1.8 id-pe-autonomousSysIds >>>>=20 >>>> In addition, RFC 6484 assigned an OID for the certificate policy. > It >> appears here in the IANA registry: >>>>=20 >>=20 > = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-number >> s-1.3.6.1.5.5.7.14 >>>>=20 >>>> The OID is: >>>> 1.3.6.1.5.5.7.14.2 id-cp-ipAddr-asNumber >>>>=20 >>>> I think this is a very good candidate for early IANA code point >> allocation. I think that our AD can assist with that. >>>>=20 >>>> Russ >>=20 >> To make sure I=E2=80=99m following along, to address the "Updates: = 3779, 6484, >> 6487 (if approved)" changes would the follow changes work: >>=20 >> 0) RFC6484-related changes >>=20 >> If we=E2=80=99re going with two OIDs (one for the original =E2=80=9Cstr= ict" validation >> and one for new =E2=80=9Crelaxed=E2=80=9D validation), then I=E2=80=99m= hoping that we can > just >> define a new OID in s1.2 of RFC 6484 and be done with it (i.e., I = hope >> we don=E2=80=99t also have to update s4.1.1, s4.5.1, and s4.7.1 where = RFC 3779 >> is mentioned). Here=E2=80=99s some text for a new section: >>=20 >> #.# Updates to RFC 6484 >>=20 >> This section replaces s1.2 of [RFC6484] with the following: >>=20 >> The name of this document is "Certificate Policy (CP) for the = Resource >> PKI (RPKI)=E2=80=9D. >>=20 >> This policy has been assigned the following two OIDs: >>=20 >> id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::=3D { iso(1) >> identified-organization(3) dod(6) internet(1) >> security(5) mechanisms(5) pkix(7) cp(14) 2 } >>=20 >> id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::=3D { iso(1) >> identified-organization(3) dod(6) internet(1) >> security(5) mechanisms(5) pkix(7) cp(14) TBD } >>=20 >> id-cp-ipAddr-asNumber and the extensions defined in [RFC3779] = indicate >> that the original certification path validation rules are to be used. >> id-cp-ipAddr-asNumber-v2 and the extensions defined in [this = document] >> indicate that the validation reconsidered certification path > validation >> rules defined in [this document] are to be used. >>=20 >>=20 >> 1) IANA registrations >>=20 >> We need to register some OIDs with IANA. Here=E2=80=99s an IANA > considerations >> section (assumes we=E2=80=99re registering a new CP OID - [] = references will > be >> to whatever section # it ends up being): >>=20 >> 6. IANA Considerations >>=20 >> IANA is to register the following five OIDs: >>=20 >> - id-cp-ipAddr-asNumber-v2 from [insert Section and #] in the SMI >> Security for PKIX Certificate Policies registry. >>=20 >> - id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2 from [insert >> Section and #] in the SMI Security for PKIX Certificate Extension >> registry. >>=20 >> - IPAddrAndASCertExtn-v2 and IPAddrAndASCertExtn-2010v2 from [insert >> Section and #] in the SMI Security for PKIX Module Identifier > registry. >>=20 >> RFC EDITOR: There are two ASN.1 modules both include the same >> assignments for id-pe-ipAddrBlocks-v2 and id-pe-autonomousSysIds-v2, >> i.e., the assignments are made by IANA once and the values are > included >> in the two modules. Please delete this prior to publication. >>=20 >>=20 >> 2) RFC3799-related changes >>=20 >> As far as RFC 3779 updates go, we probably need to update s2.3 and > s3.3 >> as well as add new ASN.1 modules. >>=20 >>=20 >> 2.1) I haven=E2=80=99t got text off the top of my head for the s2.3 = and s3.3 >> changes. >>=20 >>=20 >> 2.2) As far as the ASN.1-related changes go here=E2=80=99s two ASN.1 > module(s). >> The modules define the new OIDs and imports the syntax from >> RFC3779/RFC6268. The basic idea is to keep the modules as short as >> possible. The 2nd module is for the =E2=80=9908 ASN.1 that was = defined in RFC >> 6268 to be used with RFC5911/5912. >>=20 >> #.# =E2=80=9988 ASN.1 Module >>=20 >> IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) pkix(7) mod(0) >> id-mod-ip-addr-and-as-ident-v2(TBD) } >>=20 >> DEFINITIONS EXPLICIT TAGS ::=3D >>=20 >> BEGIN >>=20 >> -- EXPORTS ALL -- >>=20 >> IMPORTS >>=20 >> -- PKIX specific OIDs and arcs -- >>=20 >> id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3) >> dod(6) internet(1) security(5) mechanisms(5) pkix(7) >> id-mod(0) id-pkix1-explicit(18) } >>=20 >> -- IP Address Block and AS Identifiers Syntax -- >>=20 >> IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1) >> identified-organization(3) dod(6) internet(1) security(5) >> mechanisms(5) pkix(7) mod(0) >> id-mod-ip-addr-and-as-ident(30) } >> ; >>=20 >> -- Validation Reconsidered IP Address Delegation Extension OID -- >>=20 >> id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >>=20 >> -- Validation Reconsidered IP Address Delegation Extension Syntax -- >> -- Syntax is imported from [RFC3779] -- >>=20 >> -- Validation Reconsidered Autonomous System Identifier Delegation >> Extension OID -- >>=20 >> id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >>=20 >> -- Validation Reconsidered Autonomous System Identifier Delegation >> Extension Syntax -- >> -- Syntax is imported from [RFC3779] -- >>=20 >> END >>=20 >>=20 >> #.# =E2=80=9908 ASN.1 Module >>=20 >> IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) pkix(7) mod(0) >> id-mod-ip-addr-and-as-ident-2v2(TBD) } >>=20 >> DEFINITIONS EXPLICIT TAGS ::=3D >>=20 >> BEGIN >>=20 >> EXPORTS ALL; >> IMPORTS >>=20 >> -- PKIX specific OIDs and arcs =E2=80=94 >>=20 >> id-pe >> FROM PKIX1Explicit-2009 >> { iso(1) identified-organization(3) dod(6) internet(1) >> security(5) mechanisms(5) pkix(7) id-mod(0) >> id-mod-pkix1-explicit-02(51)} >>=20 >> EXTENSION >> FROM PKIX-CommonTypes-2009 >> { iso(1) identified-organization(3) dod(6) internet(1) >> security(5) mechanisms(5) pkix(7) id-mod(0) >> id-mod-pkixCommon-02(57)} >>=20 >> -- IP Address Block and AS Identifiers Syntax -- >>=20 >> IPAddrBlocks, ASIdentifiers >> FROM IPAddrAndASCertExtn-2010 >> { iso(1) identified-organization(3) dod(6) >> internet(1) security(5) mechanisms(5) pkix(7) mod(0) >> id-mod-ip-addr-and-as-ident-2(72) } >> ; >>=20 >> -- >> -- Extensions contains the set of extensions defined in this >> -- module >> -- >> -- These are intended to be placed in public key certificates >> -- and thus should be added to the CertExtensions extension >> -- set in PKIXImplicit-2009 defined for [RFC5280 >> ] >> -- >>=20 >> Extensions EXTENSION ::=3D { >> ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2 >> } >>=20 >> -- Validation Reconsidered IP Address Delegation Extension OID = =E2=80=94 >>=20 >> ext-pe-ipAddrBlocks-v2 EXTENSION ::=3D { >> SYNTAX IPAddrBlocks >> IDENTIFIED BY id-pe-ipAddrBlocks-v2 >> } >>=20 >> id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::=3D { id-pe TBD } >>=20 >> -- IP Address Delegation Extension Syntax =E2=80=94 >> -- Syntax is imported from [RFC6268] =E2=80=94 >>=20 >> -- Validation Reconsidered Autonomous System Identifier > Delegation >> Extension OID =E2=80=94 >>=20 >> ext-pe-autonomousSysIds-v2 EXTENSION ::=3D { >> SYNTAX ASIdentifiers >> IDENTIFIED BY id-pe-autonomousSysIds-v2 >> } >>=20 >> id-pe-autonomousSysIds OBJECT IDENTIFIER ::=3D { id-pe TBD } >> -- Validation Reconsidered Autonomous System Identifier Delegation >> Extension Syntax -- >> -- Syntax is imported from [RFC6268] -- >>=20 >> END >>=20 >> 2.3) If we want to be really ambitious, then right after the ASN.1 >> modules are included in the draft we could request the WG chairs = start >> an early IANA allocation request for these OID ;) >>=20 >> Cheers, >>=20 >> spt >>=20 >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- > -- >> -------- >>=20 >>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Aug 5 05:25:48 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0012D1DA; Fri, 5 Aug 2016 05:25:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160805122542.20431.88470.idtracker@ietfa.amsl.com> Date: Fri, 05 Aug 2016 05:25:42 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-adverse-actions-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 12:25:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) Authors : Stephen Kent Di Ma Filename : draft-ietf-sidr-adverse-actions-02.txt Pages : 25 Date : 2016-08-05 Abstract: This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is performed from the perspective of an affected INR holder. The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-adverse-actions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-adverse-actions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-adverse-actions-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 8 07:59:19 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDDB12D639 for ; Mon, 8 Aug 2016 07:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwxTTULAecUm for ; Mon, 8 Aug 2016 07:59:14 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1BB12D0CB for ; Mon, 8 Aug 2016 07:59:14 -0700 (PDT) X-TM-DID: 8d50bd7334eaca99b237bbf63fe25e00 From: Declan Ma Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Message-Id: <58E87CF4-2694-474F-BD48-DAB6E2BA78E4@zdns.cn> Date: Mon, 8 Aug 2016 22:54:55 +0800 To: sidr Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [sidr] Time frame for changing RPSTIR to the new validation algorithm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 14:59:18 -0000 Folks, I recall Tim has suggested a schedule for transition to the new = validation algorithm during Berlin meeting. His proposal is to mandate = RP support for the new all 6 months after the doc is published as an = RFC. My team is now responsible for RPSTIR update.=20 I am afraid that the proposal is sorta aggressive. IMHO, six-months = after publication of the RFC may be too soon. Although this WG has been = through discussions of the validation-reconsidered, but the conclusion = was just reached.=20 This is really a fundamental change to both RP and CA, I anticipate we = need more time to have RP software code changed and thoroughly tested, = to accommodate the new validation procedures.=20 Anyway, we are evaluating the time frame,trying to give absolute dates = as soon as possible. BTW, OID issue has not been yet with IANA feedbacks. We can=A1=AFt be = sure how long it will take to go through the IESG approval process, = incurring uncertainty. I am not reassured whether it is prudent to get = started with RPSTIR update right away. =20 I am therefore looking forwards to seeing more discussions and comments = in this thread, especially from other RPKI implementers. Di From nobody Tue Aug 9 04:51:02 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1112D7AA for ; Tue, 9 Aug 2016 04:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hie-fbu82j5 for ; Tue, 9 Aug 2016 04:51:00 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC21C12D5A5 for ; Tue, 9 Aug 2016 04:50:59 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bX5Yd-000A69-MP; Tue, 09 Aug 2016 13:50:56 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-88.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bX5Yd-0000Os-Hd; Tue, 09 Aug 2016 13:50:55 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Tim Bruijnzeels In-Reply-To: <58E87CF4-2694-474F-BD48-DAB6E2BA78E4@zdns.cn> Date: Tue, 9 Aug 2016 13:50:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2338C59A-F77B-4D7C-8B60-B6D577207F71@ripe.net> References: <58E87CF4-2694-474F-BD48-DAB6E2BA78E4@zdns.cn> To: Declan Ma X-Mailer: Apple Mail (2.3124) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07198aa1230e333d15c65cd425d833f770c5 Archived-At: Cc: sidr Subject: Re: [sidr] Time frame for changing RPSTIR to the new validation algorithm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 11:51:02 -0000 Hi, I am still working on an update to the document. It's encouraging to hear that another group is looking at maintaining = RPSTIR. When I discussed the 6 months with Rob we felt that this should = be doable (he can correct me if I am wrong). In our case we have had a = working implementation of the algorithm for quite some time, and those = changes by themselves are not hard. With the new OIDs we do need to = change some things around - making this dependent on OIDs rather than a = local configuration setting, but it's not a big deal. I think it's reasonable that the ability to update implementations from = both RP implementations and CA implementations should factor in to a = mandatory to implement time frame for RPs, and later CAs. But I also = believe that we should be somewhat ambitious, especially w.r.t. RPs = because their implementation is on the critical path. CAs can only start = to publish when RPs support this. Regards Tim > On 08 Aug 2016, at 16:54, Declan Ma wrote: >=20 > Folks, >=20 > I recall Tim has suggested a schedule for transition to the new = validation algorithm during Berlin meeting. His proposal is to mandate = RP support for the new all 6 months after the doc is published as an = RFC. >=20 > My team is now responsible for RPSTIR update.=20 >=20 > I am afraid that the proposal is sorta aggressive. IMHO, six-months = after publication of the RFC may be too soon. Although this WG has been = through discussions of the validation-reconsidered, but the conclusion = was just reached.=20 >=20 > This is really a fundamental change to both RP and CA, I anticipate we = need more time to have RP software code changed and thoroughly tested, = to accommodate the new validation procedures.=20 >=20 > Anyway, we are evaluating the time frame,trying to give absolute dates = as soon as possible. >=20 >=20 > BTW, OID issue has not been yet with IANA feedbacks. We can=E2=80=99t = be sure how long it will take to go through the IESG approval process, = incurring uncertainty. I am not reassured whether it is prudent to get = started with RPSTIR update right away. =20 >=20 > I am therefore looking forwards to seeing more discussions and = comments in this thread, especially from other RPKI implementers. >=20 >=20 > Di >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Aug 9 11:26:39 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1152912D0C5 for ; Tue, 9 Aug 2016 11:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmBQvLSqHYwr for ; Tue, 9 Aug 2016 11:26:35 -0700 (PDT) Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA1C12D08C for ; Tue, 9 Aug 2016 11:26:35 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id E36D313992 for ; Tue, 9 Aug 2016 18:26:33 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 7CDA9419815D for ; Tue, 9 Aug 2016 14:25:21 -0400 (EDT) Date: Tue, 09 Aug 2016 14:25:21 -0400 From: Rob Austein To: sidr@ietf.org User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20160809182521.7CDA9419815D@minas-ithil.hactrn.net> Archived-At: Subject: [sidr] rpki.net toolkit has moved to GitHub X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 18:26:37 -0000 The rpki.net toolkit (or whatever you want to call the RPKI code we've been developing for the last decade) has moved to GitHub. For details, see: https://lists.rpki.net/archives/rpki/2016-August/000300.html From nobody Fri Aug 12 15:22:17 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE67012D0DB for ; Fri, 12 Aug 2016 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1wItQtyDsWg for ; Fri, 12 Aug 2016 15:22:14 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5112312D633 for ; Fri, 12 Aug 2016 15:22:14 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C8FA928B0041 for ; Fri, 12 Aug 2016 18:22:12 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BC5941F8055; Fri, 12 Aug 2016 18:22:12 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CE1B514B-579B-449A-88A0-59BA9F8580CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Sandra Murphy In-Reply-To: Date: Fri, 12 Aug 2016 18:22:05 -0400 Message-Id: <2DACC0F3-502E-4398-8F45-8EC9466397A3@tislabs.com> References: To: sidr X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 22:22:16 -0000 --Apple-Mail=_CE1B514B-579B-449A-88A0-59BA9F8580CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99re getting close to the end date of this wglc and I have see = no comments to the mailing list. Given that this protocol is used in the RRDP protocol and this draft is = normative in the RRDP delta-protocol draft, I=E2=80=99d think there = would be some interest in reviewing it. Remember. Positive support for publication is needed. =E2=80=94Sandy, speaking as one of the wg co-chairs > On Aug 2, 2016, at 11:05 PM, Chris Morrow = wrote: >=20 >=20 > Good morning (european folks): > This starts the 2 week (14 days or 336 hr) WGLC for: > https://tools.ietf.org/html/draft-ietf-sidr-publication-08 >=20 > Abstract content: > "This document defines a protocol for publishing Resource Public Key > Infrastructure (RPKI) objects. Even though the RPKI will have many > participants issuing certificates and creating other objects, it is > operationally useful to consolidate the publication of those = objects. > This document provides the protocol for doing so." >=20 > The document has made eight, at least, revisions in the WG discussion > space, all comments are dealt with and it appears to be ready to > ascend to the next tier of existence. Please give it a read through, > and provide comments/direction in this thread. >=20 > Thanks! > -chris > co-chair --Apple-Mail=_CE1B514B-579B-449A-88A0-59BA9F8580CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXrkwTAAoJEHplpQeet0IZhhQQALe+dzEtuT+jBLiOMKBccbMx puk76tza6ph6SM0I3w6zlSeVcefyV5fRMLuJwsCJO5JqK3wGrHJRIINxIXcDtJwN n6dizSyb/Ryltpy03yqUePvtG2txWpy2fKqEGXIVNllxsVNfY88WlDeIDi4Ztvlm ZEld2W0Rz7n2sqFBDUKdBhSVwmH20L7TdaLBEPp4OaPE+1CWauN/A8toSQWOP1Nb mHO37L0us5M8anth3tysLxoG6etNZhwayNkEuD9CbH0BRF7SMRSIfQsy071ggKzA zlmWzfgJJbhsU3KctW97FnfayPAhxopk5UACU16HfE950VRA7wBfYrC1xxGZXaU0 yMp9DDi526fSrspLcaoWm/QC9CFQvWadS5TgPxiCqM7cj0yqjlaXGz/Zh1712X8H Oju+TvNvxov5cJfEHh6dmep93BZ7d6a2tDhnBf5sj4y1wvyw51ks+93j9xHQj701 x9DoNsns/n1huM73R1WanX6qXIHc+1J1ViVlL8szgzHg16ZwVdLoIwNzJK2Ft+JY NFJk6nsDOse8e+98Mp/s6Ym6rEeZC9vtnd2c0ubEqt/TxON9Cf3a3fW8a3GmMJ18 SXmDlu12q5hUaDhdI+VX3dU8t6iQb78jZsDY6kcWRSzG6SSzFhWtdtVXmwbLQUOQ DN/7jmmuS8Gg4e0nwuQH =vXlt -----END PGP SIGNATURE----- --Apple-Mail=_CE1B514B-579B-449A-88A0-59BA9F8580CE-- From nobody Fri Aug 12 17:11:03 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA47812D92E for ; Fri, 12 Aug 2016 17:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9K-zbTG2Ccb for ; Fri, 12 Aug 2016 17:11:01 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA3512D92F for ; Fri, 12 Aug 2016 17:10:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bYMXK-00034W-RJ; Sat, 13 Aug 2016 00:10:51 +0000 Date: Sat, 13 Aug 2016 09:10:48 +0900 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <2DACC0F3-502E-4398-8F45-8EC9466397A3@tislabs.com> References: <2DACC0F3-502E-4398-8F45-8EC9466397A3@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 00:11:02 -0000 have read. have used. wfm. randy From nobody Fri Aug 12 18:03:36 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9C212D56F for ; Fri, 12 Aug 2016 18:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IRUWXAeSAbq for ; Fri, 12 Aug 2016 18:03:33 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C7B12D16D for ; Fri, 12 Aug 2016 18:03:32 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id u25so1089872qtb.1 for ; Fri, 12 Aug 2016 18:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=22RywB9XhgWL268+rYg5C3nJJtmcaTif32HNvRjf68E=; b=HIg9wlZ0ID/TWje8SRzKwUb3dE9byBjoa0BRCEn8dAGgYjINj7LMtubLPnGmHdJXMg ez3y2g5mSNFKWlxC8mHQhE+M8BIVwYWqpn4CUbVkodovzErce7zV+UOYxgTnZbNBCLUN Rdn4fs8sldbQiT3rJAcMtSxKjfhS/4DB5SMkNaTNWrXEyQIM9Q7GrRcZC06bQeijbsS0 bdgouOstMYNk7jXIS6EXwz4xDgwhmvkCVG0Hhn5gBmpWddPx3DDtlBNMeZ2WQnP+9QqY VYLbtPIJAcpjDy++iuJmK6abolre5XBv5p6pHZ1Bi5V4OieCO04CBOR7/CjFTnMFZiN4 MX+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=22RywB9XhgWL268+rYg5C3nJJtmcaTif32HNvRjf68E=; b=Y2ZO6Lgnj8KRq+Us7DOCLsc6YaVJrHDBw7gMFQJpEpGIrXHYOAlRcFReGGAM5ky9vP 4pHTp+vc8Q3b+63SgQemkcbD1wTgGxD5fTcrMsc37WHCL72lMnN88xsjn5dygp979+I5 nYLqWAVdvjfxxNvZgA5RgGJGHNRRHYUoODlZlUlfapJJ5YI3fUUGJs1koyq5nxTSAL0o lGo5W6yndZd2gQVoHbWqLKH0r6TDJrdRt+8zdhVwnYSFvA8YonPU0PFd/kHkYyH14x1U 0KpH0WDGFNLjX9qXhzVMilS10B9yxfHMJ3TeHNkV+XcBN7YL8q3kRVB9dRoZGpdy0A8E Tc8g== X-Gm-Message-State: AEkoousV0kJQTu3pze40wbiYrI2vCfJQaMg/M7P7t8ATMTkClpH7dDnp7re5U70PhFyB1PNH2/jNu5m5DLBpUw== X-Received: by 10.200.38.201 with SMTP id 9mr20714535qtp.135.1471050211948; Fri, 12 Aug 2016 18:03:31 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Fri, 12 Aug 2016 18:03:31 -0700 (PDT) In-Reply-To: References: <2DACC0F3-502E-4398-8F45-8EC9466397A3@tislabs.com> From: Christopher Morrow Date: Fri, 12 Aug 2016 21:03:31 -0400 X-Google-Sender-Auth: a1TZtrIDTO-iX4H1gNcIUr7rqX8 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a1141e3b8547f830539e99175 Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 01:03:34 -0000 --001a1141e3b8547f830539e99175 Content-Type: text/plain; charset=UTF-8 terrific! one vote! more? :) (sandy's right some more folk checking through would be good, we collected a bunch of heat about needing a different option than the original transport, now we possibly have one...) On Fri, Aug 12, 2016 at 8:10 PM, Randy Bush wrote: > have read. have used. wfm. > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a1141e3b8547f830539e99175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
terrific! one vote!

more? :) (sandy'= ;s right some more folk checking through would be good, we collected a bunc= h of heat about needing a different option than the original transport, now= we possibly have one...)

On Fri, Aug 12, 2016 at 8:10 PM, Randy Bush <randy@psg.c= om> wrote:
have read.=C2=A0= have used.=C2=A0 wfm.

randy

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

--001a1141e3b8547f830539e99175-- From nobody Mon Aug 15 11:12:53 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6312D09A; Mon, 15 Aug 2016 11:12:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147128477183.31662.11637014657052045286.idtracker@ietfa.amsl.com> Date: Mon, 15 Aug 2016 11:12:51 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-slurm-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:12:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI Authors : David Mandelberg Di Ma Filename : draft-ietf-sidr-slurm-02.txt Pages : 12 Date : 2016-08-13 Abstract: The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. In the future, ISPs also will be able to use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of the RPKI to control its own network while making use of RPKI data. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-slurm-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-slurm-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 16 16:35:21 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1812D16C for ; Tue, 16 Aug 2016 16:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP5FXGnhcfBY for ; Tue, 16 Aug 2016 16:35:18 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id 88FB912D568 for ; Tue, 16 Aug 2016 16:35:17 -0700 (PDT) Received: from [192.168.11.233] (c-73-219-50-136.hsd1.ma.comcast.net [73.219.50.136]) by cyrus.watson.org (Postfix) with ESMTPSA id 04E2346B51 for ; Tue, 16 Aug 2016 19:35:15 -0400 (EDT) Date: Tue, 16 Aug 2016 19:35:14 -0400 (EDT) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:35:20 -0000 On Tue, 2 Aug 2016, Chris Morrow wrote: > Please give it a read through, and provide comments/direction in > this thread. I am content to have this version of the doc be published on the standards track. (Disclosure: I am the doc editor who made the most recent revisions to the doc.) -- Sam From nobody Wed Aug 17 09:46:37 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174E612DA17 for ; Wed, 17 Aug 2016 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APIB0hBOQc0L for ; Wed, 17 Aug 2016 09:46:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDD8B12DBFC for ; Wed, 17 Aug 2016 09:46:32 -0700 (PDT) Received: from mbp.local ([IPv6:2620:11a:c081:20:602a:5e74:b376:17ff]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7HGkTKG081260 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 17 Aug 2016 16:46:30 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:602a:5e74:b376:17ff] claimed to be mbp.local To: sidr wg list , routing-ads@ietf.org, sdir-chairs@ietf.org From: joel jaeggli Message-ID: Date: Wed, 17 Aug 2016 09:46:28 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Benoit Claise \(bclaise\)" Subject: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 16:46:36 -0000 Folks, Some discussion prior to the recent IETF led us to ask the ask the question about what to do now that SIDR is close to having achieved it's major milestones. One possible approach we have been looking at is to Charter a new activity associated with the deployment and operation of SIDR systems within networks. Here is an initial stab at a sidrops charter with the milestones drawn from existing SIDR discussion. https://datatracker.ietf.org/doc/charter-ietf-sidrops/ The global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR, is underway, creating an Internet Routing System consisting of SIDR-aware and non-SIDR-aware networks. This deployment must be properly handled to avoid the division of the Internet into separate networks, ensuring as secure a routing system as possible, through encouraged deployment of the SIDR technologies. The SIDR Operations Working Group (sidr-ops) develops guidelines for the operation of SIDR-aware networks, and provides operational guidance on how to deploy and operate SIDR technologies in new and existing networks. The main focuaess of the SIDR Operations Working Group are to: o discuss deployment and operational issues related to SIDR technologies in networks which are part of the global routing system. o gather and discuss deployment experiences with the SIDR technologies in networks which are part of the global routing system. The goals of the sidr-ops working group are: 1. Solicit input from network operators to identify operational issues with a SIDR-aware Internet, and determine solutions or workarounds to those issues. 2. Solicit input from network operators to identify operational interaction issues with the non-SIDR-aware Internet, and determine solutions or workarounds to those issues. 3. Operational solutions for identified issues should be developed in sidr-ops and documented in informational or BCP documents. These documents should document SIDR operational experience, including interactions with non-SIDR-aware networks, the interfaces between SIDR-aware and non-SIDR-aware networks, and the continued operational/security impacts from non-SIDR-aware networks. SIDR operational and deployment issues with Interdomain Routing Protocols are the primary responsibility of the IDR working gruop. However, the sidr-ops Working Group may provide input to that group, as needed, and cooperate with that group in reviewing solutions to SIDR operational and deployment problems. Future work items within this scope will be adopted by the Working Group only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the Working Group to work on a particular work item. If there is no longer sufficient interest in the Working Group in a work item, the item may be removed from the list of Working Group items. Feedback on this proposal and possible milestones above and beyond those currently present is appreciated before we circulate this for wider review. From nobody Wed Aug 17 19:45:31 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0BD12D605 for ; Wed, 17 Aug 2016 19:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txw3vpC2iUwR for ; Wed, 17 Aug 2016 19:45:20 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC85B12D7DD for ; Wed, 17 Aug 2016 19:45:17 -0700 (PDT) X-TM-DID: 23802309d4839ccccb18fb4728bc5d37 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Declan Ma In-Reply-To: Date: Thu, 18 Aug 2016 10:43:02 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> References: To: joel jaeggli X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Benoit Claise \(bclaise\)" , routing-ads@ietf.org, sdir-chairs@ietf.org, sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:45:30 -0000 Joel, When we are talking about SIDROPS, we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR = authorization information, which is created by CA and maintained by = repository managers. IMHO, network operators are not the only RPKI role that the community is = going to solicit input from. CA operators, repository operators, RP = service providers all bear significance as with SIDR Operations, in = identifying issues and sharing experiences.=20 Although network operators could also be CA operators, repository = operators, RP service providers, yet RIRs, CA and repository backend = service providers, and third party RP don=A1=AFt fall into the category = of =A1=AEnetwork operators=A1=AF. =20 I would suggest the =A1=B0The goals of the sidr-ops working group=A1=B1 = be adjusted slightly, with CA operators, repository operators, RP = service providers involved. Di > =D4=DA 2016=C4=EA8=D4=C218=C8=D5=A3=AC00:46=A3=ACjoel jaeggli = =D0=B4=B5=C0=A3=BA >=20 > Folks, >=20 > Some discussion prior to the recent IETF led us to ask the ask the > question about what to do now that SIDR is close to having achieved = it's > major milestones. One possible approach we have been looking at is to > Charter a new activity associated with the deployment and operation of > SIDR systems within networks. Here is an initial stab at a sidrops > charter with the milestones drawn from existing SIDR discussion. >=20 > https://datatracker.ietf.org/doc/charter-ietf-sidrops/ >=20 >=20 > The global deployment of RPKI, Origin Validation of BGP announcements > and BGPSEC, collectively called SIDR, is underway, creating an = Internet > Routing System consisting of SIDR-aware and non-SIDR-aware networks. > This deployment must be properly handled to avoid the division of > the Internet into separate networks, ensuring as secure a routing > system as possible, through encouraged deployment of the SIDR = technologies. >=20 > The SIDR Operations Working Group (sidr-ops) develops guidelines for > the operation of SIDR-aware networks, and provides operational = guidance > on how to deploy and operate SIDR technologies in new and existing = networks. >=20 > The main focuaess of the SIDR Operations Working Group are to: > o discuss deployment and operational issues related to SIDR = technologies > in networks which are part of the global routing system. > o gather and discuss deployment experiences with the SIDR = technologies in > networks which are part of the global routing system. >=20 > The goals of the sidr-ops working group are: >=20 > 1. Solicit input from network operators to identify > operational issues with a SIDR-aware Internet, and determine = solutions > or workarounds to those issues. >=20 > 2. Solicit input from network operators to identify > operational interaction issues with the non-SIDR-aware Internet, > and determine solutions or workarounds to those issues. >=20 > 3. Operational solutions for identified issues should be developed > in sidr-ops and documented in informational or BCP documents. >=20 > These documents should document SIDR operational experience, = including > interactions with non-SIDR-aware networks, the interfaces between = SIDR-aware > and non-SIDR-aware networks, and the continued operational/security = impacts > from non-SIDR-aware networks. >=20 > SIDR operational and deployment issues with Interdomain Routing = Protocols > are the primary responsibility of the IDR working gruop. However, = the > sidr-ops Working Group may provide input to that group, as needed, = and > cooperate with that group in reviewing solutions to SIDR operational = and > deployment problems. >=20 > Future work items within this scope will be adopted by the Working > Group only if there is a substantial expression of interest from > the community and if the work clearly does not fit elsewhere in the > IETF. >=20 > There must be a continuous expression of interest for the Working > Group to work on a particular work item. If there is no longer > sufficient interest in the Working Group in a work item, the item > may be removed from the list of Working Group items. >=20 >=20 > Feedback on this proposal and possible milestones above and beyond = those > currently present is appreciated before we circulate this for wider = review. >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Aug 17 23:50:56 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4312D0C1 for ; Wed, 17 Aug 2016 23:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJqUPyzJThen for ; Wed, 17 Aug 2016 23:50:52 -0700 (PDT) Received: from gw1.turbomail.org (gw1.turbomail.org [159.8.83.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C74912D0C0 for ; Wed, 17 Aug 2016 23:50:51 -0700 (PDT) X-TM-DID: 30b5f00c265076a8b98abc6538ddb828 From: Declan Ma Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Aug 2016 14:46:24 +0800 References: <147128477183.31662.11637014657052045286.idtracker@ietfa.amsl.com> To: sidr Message-Id: <08BF5164-8B80-419E-A0B3-44B705A1AA88@zdns.cn> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [sidr] Fwd: I-D Action: draft-ietf-sidr-slurm-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 06:50:56 -0000 Hi, folks, I just updated the slurm I-D.=20 Thanks go to Tim and Rob for sharing with me their considerations on = SLURM file format.=20 The major changes include: 1) Reorganize the layout of the intended content; 2) Rewrite the use cases; 3) Make the motivation unfocused from private INR by changing = expressions throughout the I-D and referring to = draft-ietf-sidr-adverse-actions;=20 4) Give an overview of SLURM by adding a figure of SLURM=A1=AFs Position = in the Relying Party Stack; 5) Add more text to Security Considerations; Looking forwards to your comments. Di > =CF=C2=C3=E6=CA=C7=B1=BB=D7=AA=B7=A2=B5=C4=D3=CA=BC=FE=A3=BA >=20 > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org > =D6=F7=CC=E2: [sidr] I-D Action: draft-ietf-sidr-slurm-02.txt > =C8=D5=C6=DA: 2016=C4=EA8=D4=C216=C8=D5 GMT+8 02:12:51 > =CA=D5=BC=FE=C8=CB: i-d-announce@ietf.org > =B3=AD=CB=CD: sidr@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing of the = IETF. >=20 > Title : Simplified Local internet nUmber Resource = Management with the RPKI > Authors : David Mandelberg > Di Ma > Filename : draft-ietf-sidr-slurm-02.txt > Pages : 12 > Date : 2016-08-13 >=20 > Abstract: > The Resource Public Key Infrastructure (RPKI) is a global > authorization infrastructure that allows the holder of Internet > Number Resources (INRs) to make verifiable statements about those > resources. Network operators, e.g., Internet Service Providers > (ISPs), can use the RPKI to validate BGP route origination > assertions. In the future, ISPs also will be able to use the RPKI = to > validate the path of a BGP route. However, ISPs may want to > establish a local view of the RPKI to control its own network while > making use of RPKI data. The mechanisms described in this document > provide a simple way to enable INR holders to establish a local, > customized view of the RPKI, overriding global RPKI repository data > as needed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-slurm-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-slurm-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Aug 18 07:33:11 2016 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 230BD12DAEA; Thu, 18 Aug 2016 07:33:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147153078713.22074.11881326304685200446.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 07:33:07 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:33:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : BGPsec Protocol Specification Authors : Matthew Lepinski Kotikalapudi Sriram Filename : draft-ietf-sidr-bgpsec-protocol-18.txt Pages : 35 Date : 2016-08-18 Abstract: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries a digital signature produced by each autonomous system that propagates the update message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 18 07:39:13 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA96B12DF47 for ; Thu, 18 Aug 2016 07:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM_QTuKxCt7D for ; Thu, 18 Aug 2016 07:39:08 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0108.outbound.protection.outlook.com [23.103.200.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8045C12DA8E for ; Thu, 18 Aug 2016 07:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KFAPVtSc7v7wNmzyJW3V72GJmPe/NGb8Fxdtmhb/sa0=; b=BLoNCS7L1Amzpd+xiGwuDVAWGJvtDnD51mxaVwSW7AHckg5F+F9XaDUYUKA+aPDXrRuM9FNj38MB76+8VeEdebFJDBcbRwXbYThK23L6KH1b6P0k1yFdxmsAyhP4rlHt7D11B7TrX5LPPxv5fHxXLZG64lQzvfoJKxmsE6vSZGA= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0445.namprd09.prod.outlook.com (10.161.252.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Thu, 18 Aug 2016 14:39:06 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0587.009; Thu, 18 Aug 2016 14:39:06 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "sidr wg list (sidr@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-sidr-bgpsec-protocol-18.txt Thread-Index: AQHR+V1wJHXRZUxwyE608oWGIu2/J6BOyOrg Date: Thu, 18 Aug 2016 14:39:05 +0000 Message-ID: References: <147153078730.22074.12586488256782262517.idtracker@ietfa.amsl.com> In-Reply-To: <147153078730.22074.12586488256782262517.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-ms-office365-filtering-correlation-id: 7241fe56-d789-40b4-49f9-08d3c7756842 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0445; 6:bEVIWnBRJuAKxFbn4jhbztcWmGYtEWydpp/udWH7LQaJ/YiA4pmGbD/v5R9YrS5HQ1yTs8aK4jQubjEEUy1Q3tb0wUcvGkb5ARBFgDZAmX6IBvL+7ojc/18s8m34cP7X3/kDJrVCIl4ZTKQiYqtLyRkUXdxB6Kv0Er5zIE/VePMefK85czsKsXohK55vifMGh6w/zabcgKU9LpCwhTqQkfykYl5Yrz1C33GidGGkMb+bD0KOLozRbWNuEDg993lMxHQVCpvE8vLPShUmbAeDEbB3RFji1fEE3slgxRwO7cZW7rLVwMSyScJMj8rcuGhFziPzvhJ3liKamYWxg0tzgQ==; 5:XidLMRLY1TZU2TMn/IrHoi7IHVFTfoRLmC7LwUHtDJHB4yUX2JJhJAq/0U2V7R6jOZ4YltnTFK7T+bSyuRPtjiLXZVC8tVR/PUTPir2yILn5t3+YB6RvejFKJ/vdqg2ZsRRd4js88FKBq9/QXuHedA==; 24:HjbiUSpMn+H5lawidCTBCltKcuec27Dsza1bJWUdq1/Nc+VUPts20jzKPBe5PHDtbp9RpLBrzmjOxot6v35+6fZ4/NxI756BNjD29LKnSqM=; 7:mWVbY+OBQPwZ/YMtiRPaY3G3uHxYopu+WW+weV4p7r2VM337xBhMj3bdqGbk46+0ZbywKBDAGZoEEuu9WM8pHJgbT9JK47cBkBkKqTIhF/Dp6sbR7zv1XIJ3jwBvY+FKSWqGrgSWzOp+UDwXfX/d1gd2DmYuKL7aVWiMmUJxQit7addaHC37mFVTc9ypUFU427PR9Zg+k2PJhcmfy+pCv79R7juDdSTZjVxKS7WmRqibtEpNucaZmcnqgnHnQOqL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0445; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0445; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0445; x-forefront-prvs: 0038DE95A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(199003)(189002)(13464003)(377454003)(15650500001)(97736004)(19580395003)(92566002)(76576001)(106356001)(2950100001)(10400500002)(87936001)(8676002)(15975445007)(81156014)(81166006)(77096005)(189998001)(450100001)(110136002)(74316002)(230783001)(86362001)(68736007)(107886002)(2900100001)(19580405001)(66066001)(122556002)(54356999)(7696003)(2906002)(101416001)(7736002)(102836003)(7846002)(76176999)(11100500001)(9686002)(3846002)(6116002)(106116001)(99286002)(586003)(33656002)(305945005)(50986999)(105586002)(8936002)(5002640100001)(3280700002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0445; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2016 14:39:06.1025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0445 Archived-At: Subject: [sidr] FW: New Version Notification for draft-ietf-sidr-bgpsec-protocol-18.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:39:11 -0000 VGhlIHNvdXJjZSBmaWxlIG9mIHRoaXMgZHJhZnQgd2FzIHByZXZpb3VzbHkgZm9ybWF0dGVkIGlu IG5yb2ZmLiBXZSBoYXZlIG5vdyBjb252ZXJ0ZWQgaXQgdG8geG1sLg0KVGhpcyBuZXcgdmVyc2lv biBzdWJtaXNzaW9uIGlzIGZvciB0aGF0IHJlYXNvbi4NClRoZSB4bWwgc291cmNlIGZhY2lsaXRh dGVzIGxpc3RpbmcgYW5kIGNpdGF0aW9uIG9mIHJlZmVyZW5jZXMgaW4gdGhlIHByb3BlciBSRkMg c3R5bGUuDQpJdCBhbHNvIG1ha2VzIGVkaXRpbmcgYSBiaXQgZWFzaWVyIGZvciBhbnkgZnV0dXJl IHJldmlzaW9ucy4NCg0KU3JpcmFtICAgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMTYgMTA6MzMgQU0NClRvOiBN YXR0aGV3IExlcGluc2tpIDxtbGVwaW5za2lAbmNmLmVkdT47IFNyaXJhbSwgS290aWthbGFwdWRp IChGZWQpIDxrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292Pg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sLTE4LnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3Rv Y29sLTE4LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLb3Rpa2FsYXB1 ZGkgU3JpcmFtIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LWlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wNClJldmlzaW9uOgkxOA0KVGl0bGU6CQlCR1Bz ZWMgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wOC0xOA0KR3Jv dXA6CQlzaWRyDQpQYWdlczoJCTM1DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2wtMTgudHh0 DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1wcm90b2NvbC0xOA0KRGlmZjog ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNp ZHItYmdwc2VjLXByb3RvY29sLTE4DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgQkdQc2VjLCBhbiBleHRlbnNpb24gdG8gdGhlIEJvcmRlciBHYXRld2F5DQogICBQcm90 b2NvbCAoQkdQKSB0aGF0IHByb3ZpZGVzIHNlY3VyaXR5IGZvciB0aGUgcGF0aCBvZiBhdXRvbm9t b3VzDQogICBzeXN0ZW1zIHRocm91Z2ggd2hpY2ggYSBCR1AgdXBkYXRlIG1lc3NhZ2UgcGFzc2Vz LiAgQkdQc2VjIGlzDQogICBpbXBsZW1lbnRlZCB2aWEgYW4gb3B0aW9uYWwgbm9uLXRyYW5zaXRp dmUgQkdQIHBhdGggYXR0cmlidXRlIHRoYXQNCiAgIGNhcnJpZXMgYSBkaWdpdGFsIHNpZ25hdHVy ZSBwcm9kdWNlZCBieSBlYWNoIGF1dG9ub21vdXMgc3lzdGVtIHRoYXQNCiAgIHByb3BhZ2F0ZXMg dGhlIHVwZGF0ZSBtZXNzYWdlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Aug 19 13:07:44 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6385112D18C for ; Fri, 19 Aug 2016 13:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGTUw6Q4qiyj for ; Fri, 19 Aug 2016 13:07:40 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47D4127058 for ; Fri, 19 Aug 2016 12:53:09 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 286D228B003B for ; Fri, 19 Aug 2016 15:53:09 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 164731F8036; Fri, 19 Aug 2016 15:53:09 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A5486197-D84D-454F-A526-8E49BBD1D225"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Sandra Murphy In-Reply-To: Date: Fri, 19 Aug 2016 15:53:08 -0400 Message-Id: References: To: sidr X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] wglc for draft-ietf-sidr-rpki-oob-setup-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:07:42 -0000 --Apple-Mail=_A5486197-D84D-454F-A526-8E49BBD1D225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sufficient responses received to judge wg consensus for publication. A = publication request will be coming. =97Sandy > On Jul 2, 2016, at 2:59 PM, Sandra Murphy wrote: >=20 > The authors believe that draft-ietf-sidr-rpki-oob-setup-04 ("An = Out-Of-Band Setup Protocol For RPKI Production Services=94) is mature = and ready for a working group last call. >=20 > This message starts a two week wglc for = draft-ietf-sidr-rpki-oob-setup-04, which will end 16 Jun 2016. >=20 > Please review the draft and send comments and your opinion of whether = it is worthy of publication to the list. Remember that support for = publication is needed, and comments can improve quality, so lack of = comments is not sufficient. >=20 > You can reach the document at = https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-04 and = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-oob-setup/. >=20 > =97Sandy, speaking as one of the wg co-chairs --Apple-Mail=_A5486197-D84D-454F-A526-8E49BBD1D225 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXt2OkAAoJEHplpQeet0IZyqMP/i4HYxcgz/3orVSBZITTEPGW kAcTidGoYTXXNnZuwzwD1+T9Nu+vOhBa8wmJDdOACwbBuJJflv9qogR9XdjjFyTs ubC+xkwMIKb198v9KKIyKTf3tSsFw4A+lvi5OTtcBqwdzq2wAawd9pzwJBBieIS8 jLg6tO1oCuTQ5WAzUHNX4QhQpc01A+U7uA9A2nGXHGDDws1poV8ivyNAZGw6H8Kb v4+yjzydFIWLi9Z+0opsNwOP+Zcu0JBRO3dUN1+zsAkqT9f5nU9GjRrejycwxctB MWNHRwogZ7V89i8Y+Yt+KE9eHutNbkjMqk6VWRVMD6YWoLObqYxcItNq8CDb9WmS LcFe3YnpalrAaNY1rh2Qyx2L4rJ0P4dZt68kF+wG9upOtWwtlKeeEKfFzzpaA1/z LpCtVWjI74UafvG40ILBJUeY9fY1Bo5sRwhwOdR3uUgPwlWnxDhvaU6JNW2L8JUB Iz4DCrWYpaFNGJzczHV2C3tvbQsI3ZcX7qnPZBnd5qvMQ3TddRZ/PtzMfgh15CUd m+se91GajVzaeojcAf9xeftBRja+W8alLRBSGMJeKW4Xyh6utP0apZVQTOF+gkrH qciUDnuh6cvx91lvoV8mY2U0rgkysWQJKxsN0jZhCAMygVTwdNRwPAJfQb27s0/D g4Vy/PsWZZWNpogQaOTf =pAws -----END PGP SIGNATURE----- --Apple-Mail=_A5486197-D84D-454F-A526-8E49BBD1D225-- From nobody Mon Aug 22 05:14:22 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B996912D185 for ; Mon, 22 Aug 2016 05:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTyKG88fLU2n for ; Mon, 22 Aug 2016 05:14:18 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9432712B014 for ; Mon, 22 Aug 2016 05:14:18 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1bbo7L-0007WO-Fq for sidr@ietf.org; Mon, 22 Aug 2016 14:14:17 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=[IPv6:::1]) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1bbo7K-00050I-9Q; Mon, 22 Aug 2016 14:14:14 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Oleg Muravskiy In-Reply-To: Date: Mon, 22 Aug 2016 14:14:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <726630D1-00FC-415E-AE6D-62BF7A04FE00@ripe.net> References: To: IETF SIDR X-Mailer: Apple Mail (2.2104) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: --------- X-RIPE-Spam-Report: Spam Total Points: -9.6 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b747edfb3a3e6e1ea6abd160be5f722300a Archived-At: Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:14:21 -0000 > On 17 Aug 2016, at 01:35, Samuel Weiler = wrote: >=20 > On Tue, 2 Aug 2016, Chris Morrow wrote: >=20 >> Please give it a read through, and provide comments/direction in this = thread. >=20 > I am content to have this version of the doc be published on the = standards track. (Disclosure: I am the doc editor who made the most = recent revisions to the doc.) >=20 > -- Sam In the latest revision Sam addressed all my concerns, we have a working = implementation, so it's good to go! Oleg From nobody Mon Aug 22 13:12:22 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2612D7DF for ; Mon, 22 Aug 2016 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05CTuNJbeyNA for ; Mon, 22 Aug 2016 13:12:19 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF7012D7A1 for ; Mon, 22 Aug 2016 13:12:19 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id n59so209292288uan.2 for ; Mon, 22 Aug 2016 13:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=PGoPdetE91odSDA6CqDtoCYIufR3ZGd5qPpX5IdzSLg=; b=Xn0I1gvlPIqUWT1NDAdZXzgV7WKNHwZBR5xN7YrUgxrIqpX+bGHAOX+R0wK2RQ9Lfn mEiCh9MwYYOYI6Gcrz0Q+zi+TF+FdDL7AuchOYcNeKrtGG93QGlc84OPDri8hmWlSLsv 93Ab6iLRmhcw4bYeKojRkb3xqO0mTMn1TEd0XskB0sqsonYlffcM65KGyaXULvL3q8JG sj5X+Qv4U0BTFMxWa4coZSVOS1F/GqmMvByt/ztfC+76l2++qxH1cuAgUdlR4mWMTTTh Wq+5hkJjZb0TTgTlwDDzmPTIpVzmF1PtHjrqw/1CvcJh8VO3PBkoUAAiSVAzWq6DwDpk lcXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PGoPdetE91odSDA6CqDtoCYIufR3ZGd5qPpX5IdzSLg=; b=hSrL7tsWiI9+W1oq1Y7EkNcbigd4K8zS4LcdXGTlt0JGS1SXcpA5lGTIaKV5wsyTaR kAVBeQY2G3srOQc0qc/tv0xJfQEg7ZTvdUGStnM21GjQY5RimBv3kqL6jwRj014XcUH3 MZXHF5zBxVqrcxdVHeqKRSrdC7B7hGE1Gs/GXOTn04QJyLLCOAyZOcaVYVyPw2j5BwD5 Gk4Yu6VQ62Rva2aFAv1HrA0tFEhowsQEYAND/iMXdlZbpdZAlvqKhjCjgd8c2GU/TRYt 6d+K27sPs8jcSI68/2vAlPsqtq3tdlvHLTTLWN81kCdDZAsdnQceEySLV/A5gTSLPPrj AvMg== X-Gm-Message-State: AEkoousoRXFlN6yGu6AxdPS92Be7bXT3EfvMzgCqwZS2va33nnDHQGM1CeQsI8jCDomLVg== X-Received: by 10.31.254.143 with SMTP id l137mr3599525vki.104.1471896738145; Mon, 22 Aug 2016 13:12:18 -0700 (PDT) Received: from [192.168.99.1] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id p2sm4508293vkd.4.2016.08.22.13.12.16 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 22 Aug 2016 13:12:17 -0700 (PDT) From: "Carlos M. Martinez" To: "sidr wg list" Date: Mon, 22 Aug 2016 17:12:13 -0300 Message-ID: <843C3F5F-7946-46E7-9A41-176E50925B16@gmail.com> In-Reply-To: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 20:12:21 -0000 Hi Di/all, I agree that =E2=80=98ops=E2=80=99 in the SIDR-ops space will encompass m= ore than = just network operators. I did a little text wrangling here: [https://www.dropbox.com/s/fg0x3mywc2wcxk5/sidr-ops-charter-00-carlosm.do= cx?dl=3D0] cheers! -Carlos On 17 Aug 2016, at 23:43, Declan Ma wrote: > Joel, > > When we are talking about SIDROPS, we are referring to that BGP = > speakers are resorting to RPKI relying party to get verified INR = > authorization information, which is created by CA and maintained by = > repository managers. > > IMHO, network operators are not the only RPKI role that the community = > is going to solicit input from. CA operators, repository operators, = > RP service providers all bear significance as with SIDR Operations, in = > identifying issues and sharing experiences. > > Although network operators could also be CA operators, repository = > operators, RP service providers, yet RIRs, CA and repository backend = > service providers, and third party RP don=E2=80=99t fall into the categ= ory = > of =E2=80=98network operators=E2=80=99. > > I would suggest the =E2=80=9CThe goals of the sidr-ops working group=E2= =80=9D be = > adjusted slightly, with CA operators, repository operators, RP service = > providers involved. > > > Di > >> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC=8Cjoe= l jaeggli = >> =E5=86=99=E9=81=93=EF=BC=9A >> >> Folks, >> >> Some discussion prior to the recent IETF led us to ask the ask the >> question about what to do now that SIDR is close to having achieved = >> it's >> major milestones. One possible approach we have been looking at is to >> Charter a new activity associated with the deployment and operation = >> of >> SIDR systems within networks. Here is an initial stab at a sidrops >> charter with the milestones drawn from existing SIDR discussion. >> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ >> >> >> The global deployment of RPKI, Origin Validation of BGP = >> announcements >> and BGPSEC, collectively called SIDR, is underway, creating an = >> Internet >> Routing System consisting of SIDR-aware and non-SIDR-aware networks. >> This deployment must be properly handled to avoid the division of >> the Internet into separate networks, ensuring as secure a routing >> system as possible, through encouraged deployment of the SIDR = >> technologies. >> >> The SIDR Operations Working Group (sidr-ops) develops guidelines for >> the operation of SIDR-aware networks, and provides operational = >> guidance >> on how to deploy and operate SIDR technologies in new and existing = >> networks. >> >> The main focuaess of the SIDR Operations Working Group are to: >> o discuss deployment and operational issues related to SIDR = >> technologies >> in networks which are part of the global routing system. >> o gather and discuss deployment experiences with the SIDR = >> technologies in >> networks which are part of the global routing system. >> >> The goals of the sidr-ops working group are: >> >> 1. Solicit input from network operators to identify >> operational issues with a SIDR-aware Internet, and determine = >> solutions >> or workarounds to those issues. >> >> 2. Solicit input from network operators to identify >> operational interaction issues with the non-SIDR-aware Internet, >> and determine solutions or workarounds to those issues. >> >> 3. Operational solutions for identified issues should be developed >> in sidr-ops and documented in informational or BCP documents. >> >> These documents should document SIDR operational experience, = >> including >> interactions with non-SIDR-aware networks, the interfaces between = >> SIDR-aware >> and non-SIDR-aware networks, and the continued operational/security = >> impacts >> from non-SIDR-aware networks. >> >> SIDR operational and deployment issues with Interdomain Routing = >> Protocols >> are the primary responsibility of the IDR working gruop. However, = >> the >> sidr-ops Working Group may provide input to that group, as needed, = >> and >> cooperate with that group in reviewing solutions to SIDR operational = >> and >> deployment problems. >> >> Future work items within this scope will be adopted by the Working >> Group only if there is a substantial expression of interest from >> the community and if the work clearly does not fit elsewhere in the >> IETF. >> >> There must be a continuous expression of interest for the Working >> Group to work on a particular work item. If there is no longer >> sufficient interest in the Working Group in a work item, the item >> may be removed from the list of Working Group items. >> >> >> Feedback on this proposal and possible milestones above and beyond = >> those >> currently present is appreciated before we circulate this for wider = >> review. >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Aug 22 14:04:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE01612D808 for ; Mon, 22 Aug 2016 14:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyvwN6HnJFWP for ; Mon, 22 Aug 2016 14:04:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED2712B051 for ; Mon, 22 Aug 2016 14:04:04 -0700 (PDT) Received: from mbp.local ([IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7ML3xLI011785 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Aug 2016 21:04:00 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4] claimed to be mbp.local To: Declan Ma References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> From: joel jaeggli Message-ID: Date: Mon, 22 Aug 2016 14:03:59 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HWjUcU3LkbdPD847GAhlMWn3gVa0Wj9WL" Archived-At: Cc: "Benoit Claise \(bclaise\)" , routing-ads@ietf.org, sdir-chairs@ietf.org, sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 21:04:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HWjUcU3LkbdPD847GAhlMWn3gVa0Wj9WL Content-Type: multipart/mixed; boundary="LWXUp1043FtW0dHcUrGW63NrKpItEgwuV" From: joel jaeggli To: Declan Ma Cc: sidr wg list , routing-ads@ietf.org, sdir-chairs@ietf.org, "Benoit Claise (bclaise)" Message-ID: Subject: Re: [sidr] Proposal for next steps - chartering sidrops? References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> In-Reply-To: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> --LWXUp1043FtW0dHcUrGW63NrKpItEgwuV Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: quoted-printable On 8/17/16 7:43 PM, Declan Ma wrote: > Joel, > > When we are talking about SIDROPS, we are referring to that BGP speake= rs are resorting to RPKI relying party to get verified INR authorization = information, which is created by CA and maintained by repository managers= =2E > > IMHO, network operators are not the only RPKI role that the community i= s going to solicit input from. CA operators, repository operators, RP se= rvice providers all bear significance as with SIDR Operations, in identif= ying issues and sharing experiences.=20 Yeah there are a bunch of actors who are operators of elements other than networks. RIRs and CAs spring immediately to mind. > Although network operators could also be CA operators, repository opera= tors, RP service providers, yet RIRs, CA and repository backend service p= roviders, and third party RP don=A1=AFt fall into the category of =A1=AE= network operators=A1=AF. =20 > > I would suggest the =A1=B0The goals of the sidr-ops working group=A1=B1= be adjusted slightly, with CA operators, repository operators, RP servic= e providers involved. yeah I think the tent should be inclusive. > > Di > >> =D4=DA 2016=C4=EA8=D4=C218=C8=D5=A3=AC00:46=A3=ACjoel jaeggli =D0=B4=B5=C0=A3=BA >> >> Folks, >> >> Some discussion prior to the recent IETF led us to ask the ask the >> question about what to do now that SIDR is close to having achieved it= 's >> major milestones. One possible approach we have been looking at is to >> Charter a new activity associated with the deployment and operation of= >> SIDR systems within networks. Here is an initial stab at a sidrops >> charter with the milestones drawn from existing SIDR discussion. >> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ >> >> >> The global deployment of RPKI, Origin Validation of BGP announcements= >> and BGPSEC, collectively called SIDR, is underway, creating an Intern= et >> Routing System consisting of SIDR-aware and non-SIDR-aware networks. >> This deployment must be properly handled to avoid the division of >> the Internet into separate networks, ensuring as secure a routing >> system as possible, through encouraged deployment of the SIDR technol= ogies. >> >> The SIDR Operations Working Group (sidr-ops) develops guidelines for >> the operation of SIDR-aware networks, and provides operational guidan= ce >> on how to deploy and operate SIDR technologies in new and existing ne= tworks. >> >> The main focuaess of the SIDR Operations Working Group are to: >> o discuss deployment and operational issues related to SIDR technol= ogies >> in networks which are part of the global routing system. >> o gather and discuss deployment experiences with the SIDR technolog= ies in >> networks which are part of the global routing system. >> >> The goals of the sidr-ops working group are: >> >> 1. Solicit input from network operators to identify >> operational issues with a SIDR-aware Internet, and determine solution= s >> or workarounds to those issues. >> >> 2. Solicit input from network operators to identify >> operational interaction issues with the non-SIDR-aware Internet, >> and determine solutions or workarounds to those issues. >> >> 3. Operational solutions for identified issues should be developed >> in sidr-ops and documented in informational or BCP documents. >> >> These documents should document SIDR operational experience, includin= g >> interactions with non-SIDR-aware networks, the interfaces between SID= R-aware >> and non-SIDR-aware networks, and the continued operational/security i= mpacts >> from non-SIDR-aware networks. >> >> SIDR operational and deployment issues with Interdomain Routing Proto= cols >> are the primary responsibility of the IDR working gruop. However, th= e >> sidr-ops Working Group may provide input to that group, as needed, an= d >> cooperate with that group in reviewing solutions to SIDR operational = and >> deployment problems. >> >> Future work items within this scope will be adopted by the Working >> Group only if there is a substantial expression of interest from >> the community and if the work clearly does not fit elsewhere in the >> IETF. >> >> There must be a continuous expression of interest for the Working >> Group to work on a particular work item. If there is no longer >> sufficient interest in the Working Group in a work item, the item >> may be removed from the list of Working Group items. >> >> >> Feedback on this proposal and possible milestones above and beyond tho= se >> currently present is appreciated before we circulate this for wider re= view. >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > --LWXUp1043FtW0dHcUrGW63NrKpItEgwuV-- --HWjUcU3LkbdPD847GAhlMWn3gVa0Wj9WL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAle7aL8ACgkQ8AA1q7Z/VrKk7wCfY1Sz3w03Fbr/aJYjlP74Ndh0 dioAoIVREfC6/2vbx83Pqj05BV0SE6ps =CLZ5 -----END PGP SIGNATURE----- --HWjUcU3LkbdPD847GAhlMWn3gVa0Wj9WL-- From nobody Tue Aug 23 07:42:06 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6812DAF5 for ; Tue, 23 Aug 2016 07:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2v-N_ES3djX for ; Tue, 23 Aug 2016 07:42:00 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61BA12DAFF for ; Tue, 23 Aug 2016 07:22:52 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so107831554qkc.0; Tue, 23 Aug 2016 07:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3edLKXCOi2E2aOwq/gQEPqdU2n/taJmMgMZubdy0W8I=; b=cTY9ye8J+ObiPzoF94JLF3cf/LBgNekxTnMUfvh4Lc0MmsEzwWSTK09pV42mAVd4rh CS8PHv1x0uSuUbp/nd40R8O2jMbt3xf0ikojM5O0Qqkmw37rEzoeOJLNdNd/pgEAtD6B CCinSq/acVccT2i2F4pRPmr5ScBA35S/iXxl5jeyhKkZsnjySdb/u9AqrCdHNnNHaee+ MEUhDGIP2pCV8Xh1GFrUW/lnQloiw2hKOtysp5Y30b7JOJqCyPYRkt0iWVHKdiOXzhcm fQJnZvNY0yDiFTGZdAIpBU4DGxtycEnqQLF+ogVACf0TIR84RSbMXIMSmVIwzXTMbFQJ O5og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3edLKXCOi2E2aOwq/gQEPqdU2n/taJmMgMZubdy0W8I=; b=T2bZfiP1YlCcnoK+4QDy2mnW5rgUXKFN8knWQn+TWTwA3XqXFBfVy1YOkKLtF/8VhE s9aVEOAgFwzg/HV+1JMHUnBX2z8dNAW4wJhA0w/MpBcuHi1R2TolQXAaXas45rQDXmBu 3zDoHc1NYWVEv7yrplKaP8Sb6ps8beBJXHGGcYKea7dV8nriZNxeRc4F4zBF6jYUI2du 9mi9suPG4FdbBcW6OkPqlUED6XKJ+lpxBo3ObzsQ43m1wIktGHldEaEbNA6Ixuyy4NV7 dHMm+TgBWnF9XXFE2XLcRLowHuyLNE5kiG/pUREOlAsdATKgkZRCR35xkMU7ELVvqehP jR/w== X-Gm-Message-State: AEkoousTSfmuhc2qJ5NLdVqkvWCvz9VbeqOmUBXmwdSHiPnJggeNLpEK/COkU8HztHZQXmkV5MLGaEO0Q4+wbQ== X-Received: by 10.55.120.2 with SMTP id t2mr29185602qkc.62.1471962166916; Tue, 23 Aug 2016 07:22:46 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:22:46 -0700 (PDT) In-Reply-To: References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> From: Christopher Morrow Date: Tue, 23 Aug 2016 10:22:46 -0400 X-Google-Sender-Auth: x8OZ1JJGOUPv_SGTh8uwF2V2Mxg Message-ID: To: joel jaeggli Content-Type: multipart/alternative; boundary=94eb2c05dd8c152436053abde6f0 Archived-At: Cc: "Benoit Claise \(bclaise\)" , routing-ads@ietf.org, sdir-chairs@ietf.org, sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:42:05 -0000 --94eb2c05dd8c152436053abde6f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The changes from Carlos seem ok to me, and declan's points about ca/rir also seem on point. thanks! (for fixing the clearly network centric text!) On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli wrote: > On 8/17/16 7:43 PM, Declan Ma wrote: > > Joel, > > > > When we are talking about SIDROPS, we are referring to that BGP > speakers are resorting to RPKI relying party to get verified INR > authorization information, which is created by CA and maintained by > repository managers. > > > > IMHO, network operators are not the only RPKI role that the community i= s > going to solicit input from. CA operators, repository operators, RP > service providers all bear significance as with SIDR Operations, in > identifying issues and sharing experiences. > Yeah there are a bunch of actors who are operators of elements other > than networks. > > RIRs and CAs spring immediately to mind. > > Although network operators could also be CA operators, repository > operators, RP service providers, yet RIRs, CA and repository backend > service providers, and third party RP don=E2=80=99t fall into the categor= y of > =E2=80=98network operators=E2=80=99. > > > > I would suggest the =E2=80=9CThe goals of the sidr-ops working group=E2= =80=9D be > adjusted slightly, with CA operators, repository operators, RP service > providers involved. > yeah I think the tent should be inclusive. > > > > Di > > > >> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC=8Cjoe= l jaeggli =E5=86=99=E9=81=93=EF=BC=9A > >> > >> Folks, > >> > >> Some discussion prior to the recent IETF led us to ask the ask the > >> question about what to do now that SIDR is close to having achieved it= 's > >> major milestones. One possible approach we have been looking at is to > >> Charter a new activity associated with the deployment and operation of > >> SIDR systems within networks. Here is an initial stab at a sidrops > >> charter with the milestones drawn from existing SIDR discussion. > >> > >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ > >> > >> > >> The global deployment of RPKI, Origin Validation of BGP announcements > >> and BGPSEC, collectively called SIDR, is underway, creating an Intern= et > >> Routing System consisting of SIDR-aware and non-SIDR-aware networks. > >> This deployment must be properly handled to avoid the division of > >> the Internet into separate networks, ensuring as secure a routing > >> system as possible, through encouraged deployment of the SIDR > technologies. > >> > >> The SIDR Operations Working Group (sidr-ops) develops guidelines for > >> the operation of SIDR-aware networks, and provides operational guidan= ce > >> on how to deploy and operate SIDR technologies in new and existing > networks. > >> > >> The main focuaess of the SIDR Operations Working Group are to: > >> o discuss deployment and operational issues related to SIDR > technologies > >> in networks which are part of the global routing system. > >> o gather and discuss deployment experiences with the SIDR > technologies in > >> networks which are part of the global routing system. > >> > >> The goals of the sidr-ops working group are: > >> > >> 1. Solicit input from network operators to identify > >> operational issues with a SIDR-aware Internet, and determine solution= s > >> or workarounds to those issues. > >> > >> 2. Solicit input from network operators to identify > >> operational interaction issues with the non-SIDR-aware Internet, > >> and determine solutions or workarounds to those issues. > >> > >> 3. Operational solutions for identified issues should be developed > >> in sidr-ops and documented in informational or BCP documents. > >> > >> These documents should document SIDR operational experience, includin= g > >> interactions with non-SIDR-aware networks, the interfaces between > SIDR-aware > >> and non-SIDR-aware networks, and the continued operational/security > impacts > >> from non-SIDR-aware networks. > >> > >> SIDR operational and deployment issues with Interdomain Routing > Protocols > >> are the primary responsibility of the IDR working gruop. However, th= e > >> sidr-ops Working Group may provide input to that group, as needed, an= d > >> cooperate with that group in reviewing solutions to SIDR operational > and > >> deployment problems. > >> > >> Future work items within this scope will be adopted by the Working > >> Group only if there is a substantial expression of interest from > >> the community and if the work clearly does not fit elsewhere in the > >> IETF. > >> > >> There must be a continuous expression of interest for the Working > >> Group to work on a particular work item. If there is no longer > >> sufficient interest in the Working Group in a work item, the item > >> may be removed from the list of Working Group items. > >> > >> > >> Feedback on this proposal and possible milestones above and beyond tho= se > >> currently present is appreciated before we circulate this for wider > review. > >> > >> _______________________________________________ > >> sidr mailing list > >> sidr@ietf.org > >> https://www.ietf.org/mailman/listinfo/sidr > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > --94eb2c05dd8c152436053abde6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The changes from Carlos seem ok to me, and declan's po= ints about ca/rir also seem on point.
thanks! (for fixing the clearly n= etwork centric text!)

On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <joelja@bogu= s.com> wrote:
On 8/17/16 7:43 PM, Declan Ma wrote:
> Joel,
>
> When we are talking about SIDROPS,=C2=A0 we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR authorizat= ion information, which is created by CA and maintained by repository manage= rs.
>
> IMHO, network operators are not the only RPKI role that the community = is going to solicit input from.=C2=A0 CA operators, repository operators, R= P service providers all bear significance as with SIDR Operations, in ident= ifying issues and sharing experiences.
Yeah there are a bunch of actors who are operators of elements other=
than networks.

RIRs and CAs spring immediately to mind.
> Although network operators could also be CA operators= , repository operators, RP service providers, yet RIRs, CA and repository b= ackend service providers, and third party RP don=E2=80=99t fall into the ca= tegory of=C2=A0 =E2=80=98network operators=E2=80=99.
>
> I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be adjusted slightly, with CA operators, repository operators, RP= service providers involved.
yeah I think the tent should be inclusive.
>
> Di
>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC= =8Cjoel jaeggli <joelja@bogus.com> =E5=86=99=E9=81=93=EF=BC=9A
>>
>> Folks,
>>
>> Some discussion prior to the recent IETF led us to ask the ask the=
>> question about what to do now that SIDR is close to having achieve= d it's
>> major milestones. One possible approach we have been looking at is= to
>> Charter a new activity associated with the deployment and operatio= n of
>> SIDR systems within networks. Here is an initial stab at a sidrops=
>> charter with the milestones drawn from existing SIDR discussion. >>
>> https://datatracker.ietf.org/doc= /charter-ietf-sidrops/
>>
>>
>>=C2=A0 The global deployment of RPKI, Origin Validation of BGP anno= uncements
>>=C2=A0 and BGPSEC, collectively called SIDR, is underway, creating = an Internet
>>=C2=A0 Routing System consisting of SIDR-aware and non-SIDR-aware n= etworks.
>>=C2=A0 This deployment must be properly handled to avoid the divisi= on of
>>=C2=A0 the Internet into separate networks, ensuring as secure a ro= uting
>>=C2=A0 system as possible, through encouraged deployment of the SID= R technologies.
>>
>>=C2=A0 The SIDR Operations Working Group (sidr-ops) develops guidel= ines for
>>=C2=A0 the operation of SIDR-aware networks, and provides operation= al guidance
>>=C2=A0 on how to deploy and operate SIDR technologies in new and ex= isting networks.
>>
>>=C2=A0 The main focuaess of the SIDR Operations Working Group are t= o:
>>=C2=A0 =C2=A0 o discuss deployment and operational issues related t= o SIDR technologies
>>=C2=A0 =C2=A0 =C2=A0 in networks which are part of the global routi= ng system.
>>=C2=A0 =C2=A0 o gather and discuss deployment experiences with the = SIDR technologies in
>>=C2=A0 =C2=A0 =C2=A0 networks which are part of the global routing = system.
>>
>>=C2=A0 The goals of the sidr-ops working group are:
>>
>>=C2=A0 1.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational issues with a SIDR-aware Internet, and determine= solutions
>>=C2=A0 or workarounds to those issues.
>>
>>=C2=A0 2.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational interaction issues with the non-SIDR-aware Inter= net,
>>=C2=A0 and determine solutions or workarounds to those issues.
>>
>>=C2=A0 3.=C2=A0 Operational solutions for identified issues should = be developed
>>=C2=A0 in sidr-ops and documented in informational or BCP documents= .
>>
>>=C2=A0 These documents should document SIDR operational experience,= including
>>=C2=A0 interactions with non-SIDR-aware networks, the interfaces be= tween SIDR-aware
>>=C2=A0 and non-SIDR-aware networks, and the continued operational/s= ecurity impacts
>>=C2=A0 from non-SIDR-aware networks.
>>
>>=C2=A0 SIDR operational and deployment issues with Interdomain Rout= ing Protocols
>>=C2=A0 are the primary responsibility of the IDR working gruop.=C2= =A0 However, the
>>=C2=A0 sidr-ops Working Group may provide input to that group, as n= eeded, and
>>=C2=A0 cooperate with that group in reviewing solutions to SIDR ope= rational and
>>=C2=A0 deployment problems.
>>
>>=C2=A0 Future work items within this scope will be adopted by the W= orking
>>=C2=A0 Group only if there is a substantial expression of interest = from
>>=C2=A0 the community and if the work clearly does not fit elsewhere= in the
>>=C2=A0 IETF.
>>
>>=C2=A0 There must be a continuous expression of interest for the Wo= rking
>>=C2=A0 Group to work on a particular work item.=C2=A0 If there is n= o longer
>>=C2=A0 sufficient interest in the Working Group in a work item, the= item
>>=C2=A0 may be removed from the list of Working Group items.
>>
>>
>> Feedback on this proposal and possible milestones above and beyond= those
>> currently present is appreciated before we circulate this for wide= r review.
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>



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


--94eb2c05dd8c152436053abde6f0-- From nobody Tue Aug 23 07:54:07 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B8B12DA5E; Tue, 23 Aug 2016 07:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPDPjQq1xRRn; Tue, 23 Aug 2016 07:54:02 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E439F12DA60; Tue, 23 Aug 2016 07:32:47 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id z190so108139867qkc.0; Tue, 23 Aug 2016 07:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5CZCJxlwp8Yu3UU7HEk6883CMx3SEVLkcNpu0JPmld8=; b=cWHXTh9N0sppJNtQijAZxOF5eZrG0IEjc5VP6GTrLP2TLflQRsOt1wccBC15BEXPs7 QKl5x3TyheLEu1SDjSWF5Akfbz6O4GftySJD7pztk7n4QCv3T4ABTI6ni8KpM4jhOFvx QPjQKIIXHUjriPBUzHGTe4uEg0KcIzsBDguGJbI5lLL0W/8yS4HWaapeKnUcUaM+ZkGH oAUQCnntbBjcR5vWeWeEKjBizfClTZzAunSl8hlcU1/lAzxE4N0fN+6rze0orccek+RL szlXtl9cM2CdEHk/pAdQVZH/70ZRgbkXtcg61BP0sVaGwF/hLN2gQFko9f1VYGz/2iFz U1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5CZCJxlwp8Yu3UU7HEk6883CMx3SEVLkcNpu0JPmld8=; b=mCy4YlVXzrlKZCdaC2NMbqokdH+MQpH9VofQvzds8WA5SV2q8cI344ynTh37ght5lF jKrqc4GnB6rsjADpPKbHFflNz7Ta+K2/x0JtizDb4/TZ1lD2CKmNJHgwDvvWfan1fTuY 58kjCpdw+GNyQP3fd/RK+4WtYGY3Zx2Ps/ORDa8z5TlB6PnUzTQQ8hnEWrGjEuoJ6JE8 hl+qVMNcj9DcpP2GS/DdHKqPYAqxQbVrkkw0jvrZi7M6C8WJJQb3iOnOTRGrpOnJTmUu vS1nLVb5ykddiUvsw9xTQGllGODmmyKsVhTOFIox3We2FOcJOsrrdYW/SncVVFp2YFvv jy8w== X-Gm-Message-State: AEkoousxDptkXevBEZtV7B19boZG3uKOpAtsSK7bT4epHXtKp4bQ9R9aecq17XCQf/STJ4GTBxZpLxTyP5JcPw== X-Received: by 10.55.120.2 with SMTP id t2mr29244661qkc.62.1471962762073; Tue, 23 Aug 2016 07:32:42 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:32:41 -0700 (PDT) In-Reply-To: References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> From: Christopher Morrow Date: Tue, 23 Aug 2016 10:32:41 -0400 X-Google-Sender-Auth: dCVu9rdGGkZl1lxXzlH7N-rqUcs Message-ID: To: joel jaeggli , "sidr-chairs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05dd8c8e650c053abe09bd Archived-At: Cc: "Benoit Claise \(bclaise\)" , routing-ads@ietf.org, sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:54:06 -0000 --94eb2c05dd8c8e650c053abe09bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (fixed sidr-chairs, don't know routing-ads alias, apparently) On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > The changes from Carlos seem ok to me, and declan's points about ca/rir > also seem on point. > thanks! (for fixing the clearly network centric text!) > > On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli wrote: > >> On 8/17/16 7:43 PM, Declan Ma wrote: >> > Joel, >> > >> > When we are talking about SIDROPS, we are referring to that BGP >> speakers are resorting to RPKI relying party to get verified INR >> authorization information, which is created by CA and maintained by >> repository managers. >> > >> > IMHO, network operators are not the only RPKI role that the community >> is going to solicit input from. CA operators, repository operators, RP >> service providers all bear significance as with SIDR Operations, in >> identifying issues and sharing experiences. >> Yeah there are a bunch of actors who are operators of elements other >> than networks. >> >> RIRs and CAs spring immediately to mind. >> > Although network operators could also be CA operators, repository >> operators, RP service providers, yet RIRs, CA and repository backend >> service providers, and third party RP don=E2=80=99t fall into the catego= ry of >> =E2=80=98network operators=E2=80=99. >> > >> > I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be >> adjusted slightly, with CA operators, repository operators, RP service >> providers involved. >> yeah I think the tent should be inclusive. >> > >> > Di >> > >> >> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC=8Cjo= el jaeggli =E5=86=99=E9=81=93=EF=BC=9A >> >> >> >> Folks, >> >> >> >> Some discussion prior to the recent IETF led us to ask the ask the >> >> question about what to do now that SIDR is close to having achieved >> it's >> >> major milestones. One possible approach we have been looking at is to >> >> Charter a new activity associated with the deployment and operation o= f >> >> SIDR systems within networks. Here is an initial stab at a sidrops >> >> charter with the milestones drawn from existing SIDR discussion. >> >> >> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ >> >> >> >> >> >> The global deployment of RPKI, Origin Validation of BGP announcement= s >> >> and BGPSEC, collectively called SIDR, is underway, creating an >> Internet >> >> Routing System consisting of SIDR-aware and non-SIDR-aware networks. >> >> This deployment must be properly handled to avoid the division of >> >> the Internet into separate networks, ensuring as secure a routing >> >> system as possible, through encouraged deployment of the SIDR >> technologies. >> >> >> >> The SIDR Operations Working Group (sidr-ops) develops guidelines for >> >> the operation of SIDR-aware networks, and provides operational >> guidance >> >> on how to deploy and operate SIDR technologies in new and existing >> networks. >> >> >> >> The main focuaess of the SIDR Operations Working Group are to: >> >> o discuss deployment and operational issues related to SIDR >> technologies >> >> in networks which are part of the global routing system. >> >> o gather and discuss deployment experiences with the SIDR >> technologies in >> >> networks which are part of the global routing system. >> >> >> >> The goals of the sidr-ops working group are: >> >> >> >> 1. Solicit input from network operators to identify >> >> operational issues with a SIDR-aware Internet, and determine solutio= ns >> >> or workarounds to those issues. >> >> >> >> 2. Solicit input from network operators to identify >> >> operational interaction issues with the non-SIDR-aware Internet, >> >> and determine solutions or workarounds to those issues. >> >> >> >> 3. Operational solutions for identified issues should be developed >> >> in sidr-ops and documented in informational or BCP documents. >> >> >> >> These documents should document SIDR operational experience, includi= ng >> >> interactions with non-SIDR-aware networks, the interfaces between >> SIDR-aware >> >> and non-SIDR-aware networks, and the continued operational/security >> impacts >> >> from non-SIDR-aware networks. >> >> >> >> SIDR operational and deployment issues with Interdomain Routing >> Protocols >> >> are the primary responsibility of the IDR working gruop. However, t= he >> >> sidr-ops Working Group may provide input to that group, as needed, a= nd >> >> cooperate with that group in reviewing solutions to SIDR operational >> and >> >> deployment problems. >> >> >> >> Future work items within this scope will be adopted by the Working >> >> Group only if there is a substantial expression of interest from >> >> the community and if the work clearly does not fit elsewhere in the >> >> IETF. >> >> >> >> There must be a continuous expression of interest for the Working >> >> Group to work on a particular work item. If there is no longer >> >> sufficient interest in the Working Group in a work item, the item >> >> may be removed from the list of Working Group items. >> >> >> >> >> >> Feedback on this proposal and possible milestones above and beyond >> those >> >> currently present is appreciated before we circulate this for wider >> review. >> >> >> >> _______________________________________________ >> >> sidr mailing list >> >> sidr@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sidr >> > >> >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> >> > --94eb2c05dd8c8e650c053abe09bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(fixed sidr-chairs, don't know routing-ads alias, appa= rently)

On T= ue, Aug 23, 2016 at 10:22 AM, Christopher Morrow <morrowc.lists@gmai= l.com> wrote:
The changes from Carlos seem ok to me, and declan's points about ca= /rir also seem on point.
thanks! (for fixing the clearly network centri= c text!)

On Mon, Aug 22, 2016 at 5:03 PM,= joel jaeggli <joelja@bogus.com> wrote:
On 8/17/16 7:43 PM, Declan Ma wrote:
> Joel,
>
> When we are talking about SIDROPS,=C2=A0 we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR authorizat= ion information, which is created by CA and maintained by repository manage= rs.
>
> IMHO, network operators are not the only RPKI role that the community = is going to solicit input from.=C2=A0 CA operators, repository operators, R= P service providers all bear significance as with SIDR Operations, in ident= ifying issues and sharing experiences.
Yeah there are a bunch of actors who are operators of elements other=
than networks.

RIRs and CAs spring immediately to mind.
> Although network operators could also be CA operators, repositor= y operators, RP service providers, yet RIRs, CA and repository backend serv= ice providers, and third party RP don=E2=80=99t fall into the category of= =C2=A0 =E2=80=98network operators=E2=80=99.
>
> I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be adjusted slightly, with CA operators, repository operators, RP= service providers involved.
yeah I think the tent should be inclusive.
>
> Di
>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC= =8Cjoel jaeggli <j= oelja@bogus.com> =E5=86=99=E9=81=93=EF=BC=9A
>>
>> Folks,
>>
>> Some discussion prior to the recent IETF led us to ask the ask the=
>> question about what to do now that SIDR is close to having achieve= d it's
>> major milestones. One possible approach we have been looking at is= to
>> Charter a new activity associated with the deployment and operatio= n of
>> SIDR systems within networks. Here is an initial stab at a sidrops=
>> charter with the milestones drawn from existing SIDR discussion. >>
>> https://datatracker.ietf.org/doc= /charter-ietf-sidrops/
>>
>>
>>=C2=A0 The global deployment of RPKI, Origin Validation of BGP anno= uncements
>>=C2=A0 and BGPSEC, collectively called SIDR, is underway, creating = an Internet
>>=C2=A0 Routing System consisting of SIDR-aware and non-SIDR-aware n= etworks.
>>=C2=A0 This deployment must be properly handled to avoid the divisi= on of
>>=C2=A0 the Internet into separate networks, ensuring as secure a ro= uting
>>=C2=A0 system as possible, through encouraged deployment of the SID= R technologies.
>>
>>=C2=A0 The SIDR Operations Working Group (sidr-ops) develops guidel= ines for
>>=C2=A0 the operation of SIDR-aware networks, and provides operation= al guidance
>>=C2=A0 on how to deploy and operate SIDR technologies in new and ex= isting networks.
>>
>>=C2=A0 The main focuaess of the SIDR Operations Working Group are t= o:
>>=C2=A0 =C2=A0 o discuss deployment and operational issues related t= o SIDR technologies
>>=C2=A0 =C2=A0 =C2=A0 in networks which are part of the global routi= ng system.
>>=C2=A0 =C2=A0 o gather and discuss deployment experiences with the = SIDR technologies in
>>=C2=A0 =C2=A0 =C2=A0 networks which are part of the global routing = system.
>>
>>=C2=A0 The goals of the sidr-ops working group are:
>>
>>=C2=A0 1.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational issues with a SIDR-aware Internet, and determine= solutions
>>=C2=A0 or workarounds to those issues.
>>
>>=C2=A0 2.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational interaction issues with the non-SIDR-aware Inter= net,
>>=C2=A0 and determine solutions or workarounds to those issues.
>>
>>=C2=A0 3.=C2=A0 Operational solutions for identified issues should = be developed
>>=C2=A0 in sidr-ops and documented in informational or BCP documents= .
>>
>>=C2=A0 These documents should document SIDR operational experience,= including
>>=C2=A0 interactions with non-SIDR-aware networks, the interfaces be= tween SIDR-aware
>>=C2=A0 and non-SIDR-aware networks, and the continued operational/s= ecurity impacts
>>=C2=A0 from non-SIDR-aware networks.
>>
>>=C2=A0 SIDR operational and deployment issues with Interdomain Rout= ing Protocols
>>=C2=A0 are the primary responsibility of the IDR working gruop.=C2= =A0 However, the
>>=C2=A0 sidr-ops Working Group may provide input to that group, as n= eeded, and
>>=C2=A0 cooperate with that group in reviewing solutions to SIDR ope= rational and
>>=C2=A0 deployment problems.
>>
>>=C2=A0 Future work items within this scope will be adopted by the W= orking
>>=C2=A0 Group only if there is a substantial expression of interest = from
>>=C2=A0 the community and if the work clearly does not fit elsewhere= in the
>>=C2=A0 IETF.
>>
>>=C2=A0 There must be a continuous expression of interest for the Wo= rking
>>=C2=A0 Group to work on a particular work item.=C2=A0 If there is n= o longer
>>=C2=A0 sufficient interest in the Working Group in a work item, the= item
>>=C2=A0 may be removed from the list of Working Group items.
>>
>>
>> Feedback on this proposal and possible milestones above and beyond= those
>> currently present is appreciated before we circulate this for wide= r review.
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>



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



--94eb2c05dd8c8e650c053abe09bd-- From nobody Tue Aug 23 08:03:50 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FB12DB4F for ; Tue, 23 Aug 2016 08:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSqirB6rT1ab for ; Tue, 23 Aug 2016 08:03:44 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD5E12D54D for ; Tue, 23 Aug 2016 07:40:53 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id w38so42008630qtb.0 for ; Tue, 23 Aug 2016 07:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rkUlxDSsrzaYNM+cHoonFkbwrf0WSO/I9YmtKWLG8Vw=; b=FcEFsJYC4MfQMqkTp/WfuDdQXqhfbASmwH4EY+arqOri3f2KLyROTFRBmphw73jDMF WFAG2I4uNo8iwixBsYHf/ZV1e2DYP7FYuYuWMn5sfPYbxY9ju0rFzOU4b6wy+AFNE0fm 42mRgH9kg/BD5TVqXVIA02+VOFFgoNqdj38ATEyPhmjUP/+o1QzioRXkOXuMX8H8oYhD 2gUqAVmSAo4WAsgU0QeMYHy9IkUgMQzMZVywE2q924I2fXA4NjcYDjYrF03r1hibmUB2 3oqPAIoN8Gpdg4NrLp6UPEVjF5Ojy3cYZsnUjSV1G5f6C50Mk/0TFwcqWjOiLGYHUIoK Ktww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rkUlxDSsrzaYNM+cHoonFkbwrf0WSO/I9YmtKWLG8Vw=; b=GOk3DnaKJMBMLMUpjxzQ5w2ctjjQpci24qN6MqzLfr2yso50ecD1Blf+WBWDzPq0qB Y7cdWFaBny7NvMZjj9IW47ba9SyBgBJ5M/RpusMqX1d8ckqfG9InN5HDStsSXU6TPvnp NPW9IpBUcDsBfg6QrxKupIIGkkTELXyxqDJFP841Q1l8SBlY2vyjjIbEwuTyfSK/mz+O Pyc4BB6bJB5ANuOeR9gnKtIPkcTjbxHBk349WCLZUOvJseQ89GpBPwd5R6NJ35UvtWT6 4o3QZFtTdKrWLMeUDV6y2qremmAqV6IAj4btX6HpZwUx95sxgvcFj+bm6fGzaNM8ENFg OAKA== X-Gm-Message-State: AEkooutHXlxVRizCKaR4O6h/UWb1gRbnYgd2y6j2amp8g0VIIJltBRn19I/UnEVpq/d23ogzkxrtAtHwxkMSXw== X-Received: by 10.237.47.225 with SMTP id m88mr30929155qtd.106.1471963252143; Tue, 23 Aug 2016 07:40:52 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:40:51 -0700 (PDT) In-Reply-To: <726630D1-00FC-415E-AE6D-62BF7A04FE00@ripe.net> References: <726630D1-00FC-415E-AE6D-62BF7A04FE00@ripe.net> From: Christopher Morrow Date: Tue, 23 Aug 2016 10:40:51 -0400 X-Google-Sender-Auth: 1CMogRvNGP_WAa_ej8vr4nY7tXc Message-ID: To: Oleg Muravskiy Content-Type: multipart/alternative; boundary=94eb2c123170c43ff3053abe267e Archived-At: Cc: IETF SIDR Subject: Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:03:49 -0000 --94eb2c123170c43ff3053abe267e Content-Type: text/plain; charset=UTF-8 great! once I get back to the office (monday) I'll send out the upstream request. On Mon, Aug 22, 2016 at 8:14 AM, Oleg Muravskiy wrote: > > > On 17 Aug 2016, at 01:35, Samuel Weiler wrote: > > > > On Tue, 2 Aug 2016, Chris Morrow wrote: > > > >> Please give it a read through, and provide comments/direction in this > thread. > > > > I am content to have this version of the doc be published on the > standards track. (Disclosure: I am the doc editor who made the most recent > revisions to the doc.) > > > > -- Sam > > In the latest revision Sam addressed all my concerns, we have a working > implementation, so it's good to go! > > Oleg > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --94eb2c123170c43ff3053abe267e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
great! once I get back to the office (monday) I'll sen= d out the upstream request.

On Mon, Aug 22, 2016 at 8:14 AM, Oleg Muravskiy <oleg@ripe.n= et> wrote:

> On 17 Aug 2016, at 01:35, Samuel Weiler <weiler+ietf@watson.org> wrote:
>
> On Tue, 2 Aug 2016, Chris Morrow wrote:
>
>> Please give it a read through, and provide comments/direction in t= his thread.
>
> I am content to have this version of the doc be published on the stand= ards track.=C2=A0 (Disclosure: I am the doc editor who made the most recent= revisions to the doc.)
>
> -- Sam

In the latest revision Sam addressed all my concerns, we have a work= ing implementation, so it's good to go!

Oleg

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

--94eb2c123170c43ff3053abe267e-- From nobody Tue Aug 23 08:13:59 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32CC512DA10; Tue, 23 Aug 2016 08:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MV-gFZjBVRB; Tue, 23 Aug 2016 08:13:55 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480E912DA13; Tue, 23 Aug 2016 07:48:02 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v123so108499458qkh.2; Tue, 23 Aug 2016 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zSoU5FxVo3IRqVIPI29QW7NHo2uX9uep7rHKV46SMzg=; b=TXxFjX3wfIlJBs3eTbyUVli9A+VwOjdQvlQIoEEKzepc5h/QhTLvO9GDnVGf/AxuMT 0P1EbfYpNYrDWojpsxd0+1wKjetOMQ7pmDJCm3ycBrWFJq7iGdlDgfWffCcNhfDkFPbB HxrFjsM5mzC+XRRpHJCfpKdwcq12jXfMtrf5RpBEWSUXv1jffJ5iqXfxkimiiMCF1jPP O3uZa9yzx5tjTDwb93O1qFAJ+HTEgI5ffpT6zgEO9Tn6IZ0AGVaGr3YeBKcnenxoQ6fQ I/DRyN1Ug2NgEEEn1E8L43l1vV7xI10cvQpQE2m6pWjQyFjZdEU2Ioap+jol5nJtHEtv HlOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zSoU5FxVo3IRqVIPI29QW7NHo2uX9uep7rHKV46SMzg=; b=P5l2myvQsoizp4mRm8r78ROMogZQfnpPNksa5lHInufHxkBwuA+ySVtbLlhx5nupTj J9bwrhDr6Fbe+JSXPRk9C4sgqbf6FxsGbTEi2HqxBnhYoa0gOgIEFmYNTA79//m3I1bk VInXoQy05jsh3buSFwMHSfaGfQCKaEHY6+7qtJvbO6vjTDfyj3KMlAlQ0kU1D5eWY9Ah D11YE6Zr7BRDYVKNeM0y1xm7LT2sD2LuvlxLex0/UB8r7LUK5FQk5kTFT1COhHeZlGzF k9SODUvg1cbPMi25rBkmQvXuwDyq+N4g39Xno30//lTbPyiH7n4wGg704sSfuyV0LOb0 W6mQ== X-Gm-Message-State: AEkoouuunglJCDsE7tiSQYCf8TD/JojYFZKLdqHf3YxXFxnpSFvYpkpfY3XqSMnYuAt2h+KhgQ0a/db/VwfpjQ== X-Received: by 10.233.222.133 with SMTP id s127mr31487731qkf.166.1471963681313; Tue, 23 Aug 2016 07:48:01 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:48:00 -0700 (PDT) In-Reply-To: References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> From: Christopher Morrow Date: Tue, 23 Aug 2016 10:48:00 -0400 X-Google-Sender-Auth: UfIdQE33i_9K1VOACi5g2bFA15g Message-ID: To: joel jaeggli , "sidr-chairs@ietf.org" , rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c0438f858da0c053abe4094 Archived-At: Cc: "Benoit Claise \(bclaise\)" , sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:13:58 -0000 --94eb2c0438f858da0c053abe4094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable routing-ads -> rtg-ads. On Tue, Aug 23, 2016 at 10:32 AM, Christopher Morrow < morrowc.lists@gmail.com> wrote: > (fixed sidr-chairs, don't know routing-ads alias, apparently) > > On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow < > morrowc.lists@gmail.com> wrote: > >> The changes from Carlos seem ok to me, and declan's points about ca/rir >> also seem on point. >> thanks! (for fixing the clearly network centric text!) >> >> On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli wrote: >> >>> On 8/17/16 7:43 PM, Declan Ma wrote: >>> > Joel, >>> > >>> > When we are talking about SIDROPS, we are referring to that BGP >>> speakers are resorting to RPKI relying party to get verified INR >>> authorization information, which is created by CA and maintained by >>> repository managers. >>> > >>> > IMHO, network operators are not the only RPKI role that the community >>> is going to solicit input from. CA operators, repository operators, RP >>> service providers all bear significance as with SIDR Operations, in >>> identifying issues and sharing experiences. >>> Yeah there are a bunch of actors who are operators of elements other >>> than networks. >>> >>> RIRs and CAs spring immediately to mind. >>> > Although network operators could also be CA operators, repository >>> operators, RP service providers, yet RIRs, CA and repository backend >>> service providers, and third party RP don=E2=80=99t fall into the categ= ory of >>> =E2=80=98network operators=E2=80=99. >>> > >>> > I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be >>> adjusted slightly, with CA operators, repository operators, RP service >>> providers involved. >>> yeah I think the tent should be inclusive. >>> > >>> > Di >>> > >>> >> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC=8Cj= oel jaeggli =E5=86=99=E9=81=93=EF=BC=9A >>> >> >>> >> Folks, >>> >> >>> >> Some discussion prior to the recent IETF led us to ask the ask the >>> >> question about what to do now that SIDR is close to having achieved >>> it's >>> >> major milestones. One possible approach we have been looking at is t= o >>> >> Charter a new activity associated with the deployment and operation = of >>> >> SIDR systems within networks. Here is an initial stab at a sidrops >>> >> charter with the milestones drawn from existing SIDR discussion. >>> >> >>> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ >>> >> >>> >> >>> >> The global deployment of RPKI, Origin Validation of BGP announcemen= ts >>> >> and BGPSEC, collectively called SIDR, is underway, creating an >>> Internet >>> >> Routing System consisting of SIDR-aware and non-SIDR-aware networks= . >>> >> This deployment must be properly handled to avoid the division of >>> >> the Internet into separate networks, ensuring as secure a routing >>> >> system as possible, through encouraged deployment of the SIDR >>> technologies. >>> >> >>> >> The SIDR Operations Working Group (sidr-ops) develops guidelines fo= r >>> >> the operation of SIDR-aware networks, and provides operational >>> guidance >>> >> on how to deploy and operate SIDR technologies in new and existing >>> networks. >>> >> >>> >> The main focuaess of the SIDR Operations Working Group are to: >>> >> o discuss deployment and operational issues related to SIDR >>> technologies >>> >> in networks which are part of the global routing system. >>> >> o gather and discuss deployment experiences with the SIDR >>> technologies in >>> >> networks which are part of the global routing system. >>> >> >>> >> The goals of the sidr-ops working group are: >>> >> >>> >> 1. Solicit input from network operators to identify >>> >> operational issues with a SIDR-aware Internet, and determine >>> solutions >>> >> or workarounds to those issues. >>> >> >>> >> 2. Solicit input from network operators to identify >>> >> operational interaction issues with the non-SIDR-aware Internet, >>> >> and determine solutions or workarounds to those issues. >>> >> >>> >> 3. Operational solutions for identified issues should be developed >>> >> in sidr-ops and documented in informational or BCP documents. >>> >> >>> >> These documents should document SIDR operational experience, >>> including >>> >> interactions with non-SIDR-aware networks, the interfaces between >>> SIDR-aware >>> >> and non-SIDR-aware networks, and the continued operational/security >>> impacts >>> >> from non-SIDR-aware networks. >>> >> >>> >> SIDR operational and deployment issues with Interdomain Routing >>> Protocols >>> >> are the primary responsibility of the IDR working gruop. However, >>> the >>> >> sidr-ops Working Group may provide input to that group, as needed, >>> and >>> >> cooperate with that group in reviewing solutions to SIDR operationa= l >>> and >>> >> deployment problems. >>> >> >>> >> Future work items within this scope will be adopted by the Working >>> >> Group only if there is a substantial expression of interest from >>> >> the community and if the work clearly does not fit elsewhere in the >>> >> IETF. >>> >> >>> >> There must be a continuous expression of interest for the Working >>> >> Group to work on a particular work item. If there is no longer >>> >> sufficient interest in the Working Group in a work item, the item >>> >> may be removed from the list of Working Group items. >>> >> >>> >> >>> >> Feedback on this proposal and possible milestones above and beyond >>> those >>> >> currently present is appreciated before we circulate this for wider >>> review. >>> >> >>> >> _______________________________________________ >>> >> sidr mailing list >>> >> sidr@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/sidr >>> > >>> >>> >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> >>> >> > --94eb2c0438f858da0c053abe4094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
routing-ads -> rtg-ads.

On Tue, Aug 23, 2016 at 10:32 AM, Christoph= er Morrow <morrowc.lists@gmail.com> wrote:
(fixed sidr-chairs, don't know = routing-ads alias, apparently)

On Tue, Aug 23, = 2016 at 10:22 AM, Christopher Morrow <morrowc.lists@gmail.com>= ; wrote:
The chan= ges from Carlos seem ok to me, and declan's points about ca/rir also se= em on point.
thanks! (for fixing the clearly network centric text!)

On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <joelja@bogus.com> wrote:
On 8/17/16 7:43 PM, Dec= lan Ma wrote:
> Joel,
>
> When we are talking about SIDROPS,=C2=A0 we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR authorizat= ion information, which is created by CA and maintained by repository manage= rs.
>
> IMHO, network operators are not the only RPKI role that the community = is going to solicit input from.=C2=A0 CA operators, repository operators, R= P service providers all bear significance as with SIDR Operations, in ident= ifying issues and sharing experiences.
Yeah there are a bunch of actors who are operators of elements other=
than networks.

RIRs and CAs spring immediately to mind.
> Although network operators could also be CA operators, repositor= y operators, RP service providers, yet RIRs, CA and repository backend serv= ice providers, and third party RP don=E2=80=99t fall into the category of= =C2=A0 =E2=80=98network operators=E2=80=99.
>
> I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be adjusted slightly, with CA operators, repository operators, RP= service providers involved.
yeah I think the tent should be inclusive.
>
> Di
>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC= =8Cjoel jaeggli <j= oelja@bogus.com> =E5=86=99=E9=81=93=EF=BC=9A
>>
>> Folks,
>>
>> Some discussion prior to the recent IETF led us to ask the ask the=
>> question about what to do now that SIDR is close to having achieve= d it's
>> major milestones. One possible approach we have been looking at is= to
>> Charter a new activity associated with the deployment and operatio= n of
>> SIDR systems within networks. Here is an initial stab at a sidrops=
>> charter with the milestones drawn from existing SIDR discussion. >>
>> https://datatracker.ietf.org/doc= /charter-ietf-sidrops/
>>
>>
>>=C2=A0 The global deployment of RPKI, Origin Validation of BGP anno= uncements
>>=C2=A0 and BGPSEC, collectively called SIDR, is underway, creating = an Internet
>>=C2=A0 Routing System consisting of SIDR-aware and non-SIDR-aware n= etworks.
>>=C2=A0 This deployment must be properly handled to avoid the divisi= on of
>>=C2=A0 the Internet into separate networks, ensuring as secure a ro= uting
>>=C2=A0 system as possible, through encouraged deployment of the SID= R technologies.
>>
>>=C2=A0 The SIDR Operations Working Group (sidr-ops) develops guidel= ines for
>>=C2=A0 the operation of SIDR-aware networks, and provides operation= al guidance
>>=C2=A0 on how to deploy and operate SIDR technologies in new and ex= isting networks.
>>
>>=C2=A0 The main focuaess of the SIDR Operations Working Group are t= o:
>>=C2=A0 =C2=A0 o discuss deployment and operational issues related t= o SIDR technologies
>>=C2=A0 =C2=A0 =C2=A0 in networks which are part of the global routi= ng system.
>>=C2=A0 =C2=A0 o gather and discuss deployment experiences with the = SIDR technologies in
>>=C2=A0 =C2=A0 =C2=A0 networks which are part of the global routing = system.
>>
>>=C2=A0 The goals of the sidr-ops working group are:
>>
>>=C2=A0 1.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational issues with a SIDR-aware Internet, and determine= solutions
>>=C2=A0 or workarounds to those issues.
>>
>>=C2=A0 2.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational interaction issues with the non-SIDR-aware Inter= net,
>>=C2=A0 and determine solutions or workarounds to those issues.
>>
>>=C2=A0 3.=C2=A0 Operational solutions for identified issues should = be developed
>>=C2=A0 in sidr-ops and documented in informational or BCP documents= .
>>
>>=C2=A0 These documents should document SIDR operational experience,= including
>>=C2=A0 interactions with non-SIDR-aware networks, the interfaces be= tween SIDR-aware
>>=C2=A0 and non-SIDR-aware networks, and the continued operational/s= ecurity impacts
>>=C2=A0 from non-SIDR-aware networks.
>>
>>=C2=A0 SIDR operational and deployment issues with Interdomain Rout= ing Protocols
>>=C2=A0 are the primary responsibility of the IDR working gruop.=C2= =A0 However, the
>>=C2=A0 sidr-ops Working Group may provide input to that group, as n= eeded, and
>>=C2=A0 cooperate with that group in reviewing solutions to SIDR ope= rational and
>>=C2=A0 deployment problems.
>>
>>=C2=A0 Future work items within this scope will be adopted by the W= orking
>>=C2=A0 Group only if there is a substantial expression of interest = from
>>=C2=A0 the community and if the work clearly does not fit elsewhere= in the
>>=C2=A0 IETF.
>>
>>=C2=A0 There must be a continuous expression of interest for the Wo= rking
>>=C2=A0 Group to work on a particular work item.=C2=A0 If there is n= o longer
>>=C2=A0 sufficient interest in the Working Group in a work item, the= item
>>=C2=A0 may be removed from the list of Working Group items.
>>
>>
>> Feedback on this proposal and possible milestones above and beyond= those
>> currently present is appreciated before we circulate this for wide= r review.
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>



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




--94eb2c0438f858da0c053abe4094-- From nobody Tue Aug 23 18:05:42 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6F12DB46 for ; Tue, 23 Aug 2016 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXuRBlnwX2lF for ; Tue, 23 Aug 2016 18:05:40 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5152312DC01 for ; Tue, 23 Aug 2016 18:05:40 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z190so1735287qkc.0 for ; Tue, 23 Aug 2016 18:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qfcfy2oPcEu3x3FVlveafZG6C0HN88MetN434hJhy2U=; b=f/HIQ4+j5LW2gRiu8v+d3p7VboDga6Hk315lRC5togr2k0W2le5CGSl+8QU/ZSUtE5 WhBTllpDzJQCii6P//iLbV2VIqttWc6vedqfQMye1zgzbCdmy10QeX9nsOtCarNTKtfQ LQdQxbGTriMy+RMm4iAhyV3Fnw94dHPeXTsJE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qfcfy2oPcEu3x3FVlveafZG6C0HN88MetN434hJhy2U=; b=VE8i7VH3EBf+yPKPZh5sP8Ih6STeaurJlFAvdV1rzW1ichrU6cX9QBjLRhgGwyO6Xi x1mJ5zwiCrGd3R9vAlyJxLgdlvupV8syohDhXg1ku+jZPBAUywTG11dtJPASBQ43X03c jm5Y1ZcVJg312dcnGTSSQefgcH2BIRSVPDypds/B87U6XpmV74ZFiS1yBZjqFprt9H3n dN05LbEZZr3Wvh7IuVXwRVPXWHjyocevJ+T1QEc2llN+MBy9M9ngLjgJ3JwD/zRWsgUj +EbGzHnnqqSmf9HVss/mRWKefKan62DhFGwcGGI4hE9p4cpa7LqNw74csvk6EcHmzenb kBjw== X-Gm-Message-State: AE9vXwOXNmTxPP1tzFWOiIOJzSMJ3E+CpcV4FAMSJ3D0QXCwnbUGwo5DPO61e6DwZDD8Og== X-Received: by 10.55.114.193 with SMTP id n184mr406554qkc.4.1472000739484; Tue, 23 Aug 2016 18:05:39 -0700 (PDT) Received: from [172.16.0.112] (pool-173-73-120-170.washdc.east.verizon.net. [173.73.120.170]) by smtp.gmail.com with ESMTPSA id w67sm3269627qkb.45.2016.08.23.18.05.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 18:05:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 23 Aug 2016 21:05:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99C86FCF-6095-46BB-9B66-FC9B193EE4EC@sn3rd.com> References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> To: joel jaeggli X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Benoit Claise , routing-ads@ietf.org, sdir-chairs@ietf.org, sidr wg list Subject: Re: [sidr] Proposal for next steps - chartering sidrops? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 01:05:41 -0000 > On Aug 22, 2016, at 17:03, joel jaeggli wrote: >=20 > On 8/17/16 7:43 PM, Declan Ma wrote: >> Joel, >>=20 >> When we are talking about SIDROPS, we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR = authorization information, which is created by CA and maintained by = repository managers. >>=20 >> IMHO, network operators are not the only RPKI role that the community = is going to solicit input from. CA operators, repository operators, RP = service providers all bear significance as with SIDR Operations, in = identifying issues and sharing experiences.=20 > Yeah there are a bunch of actors who are operators of elements other > than networks. >=20 > RIRs and CAs spring immediately to mind. >> Although network operators could also be CA operators, repository = operators, RP service providers, yet RIRs, CA and repository backend = service providers, and third party RP don=E2=80=99t fall into the = category of =E2=80=98network operators=E2=80=99. =20 >>=20 >> I would suggest the =E2=80=9CThe goals of the sidr-ops working = group=E2=80=9D be adjusted slightly, with CA operators, repository = operators, RP service providers involved. > yeah I think the tent should be inclusive. I agree with Di+Joel so +1. spt= From nobody Wed Aug 31 18:37:09 2016 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3D12B040; Wed, 31 Aug 2016 18:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5m09K_l8yfk; Wed, 31 Aug 2016 18:37:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF7912B03A; Wed, 31 Aug 2016 18:37:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7D593B80D09; Wed, 31 Aug 2016 18:37:02 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160901013702.7D593B80D09@rfc-editor.org> Date: Wed, 31 Aug 2016 18:37:02 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] RFC 7935 on The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 01:37:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7935 Title: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure Author: G. Huston, G. Michaelson, Ed. Status: Standards Track Stream: IETF Date: August 2016 Mailbox: gih@apnic.net, ggm@apnic.net Pages: 9 Characters: 17952 Obsoletes: RFC 6485 I-D Tag: draft-ietf-sidr-rfc6485bis-05.txt URL: https://www.rfc-editor.org/info/rfc7935 DOI: http://dx.doi.org/10.17487/RFC7935 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC