From nobody Thu Nov 2 06:20:50 2017 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 62AA6139561; Thu, 2 Nov 2017 06:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 TOCCybxjGXL0; Thu, 2 Nov 2017 06:20:35 -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 4C6E71397F9; Thu, 2 Nov 2017 06:20:35 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eAFQ7-000BLV-8X; Thu, 02 Nov 2017 14:20:32 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-246.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eAFQ7-0003CO-3q; Thu, 02 Nov 2017 14:20:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: Date: Thu, 2 Nov 2017 14:20:30 +0100 Cc: Ben Campbell , Terry Manderson , sidr chairs , Chris Morrow , "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , The IESG , "sidr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <902ADA93-8D4B-4D0A-BD9B-F400083CC68E@ripe.net> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> <58459EC7-14B4-4F27-929B-3BB9017C48A8@nostrum.com> <467A9EB7-8112-43C3-A4CD-6E51E93B5660@ripe.net> To: Alvaro Retana X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e573abb945025f8cf5bf69ca9c9029dc Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:20:42 -0000 Alvaro, Ben, Given that I will meet with my co-authors in person at IETF100 I would = like to take the opportunity to discuss things there with them in person = and then get back to the list. Will both of you be there as well by = chance? I think we could benefit from a chat in person in order to make = updates more efficiently. Tim > On 30 Oct 2017, at 20:45, Alvaro Retana = wrote: >=20 > Tim: >=20 > Hi! >=20 > FWIW, I agree with Ben that the text doesn=E2=80=99t resolve his = concerns, and it doesn=E2=80=99t reflect what you said on the thread. I = think you two are actually saying the same thing (or pretty close), but = using different words. =20 >=20 > I think that at least (+ the specific points made by Ben below) the = text needs to explicitly expand the new Abstract text throughout the = rest of the document, potentially include an example of mixed OIDs, and = talk about the use of the new OIDs in with the old procedure. Some of = these things are sort of implicit already; for example, using the new = OIDs with the old procedure is not specified in rfc6487=E2=80=A6but = explicitly mentioning it in this document won=E2=80=99t hurt. >=20 > Thanks! >=20 > Alvaro. >=20 > On October 27, 2017 at 5:57:08 PM, Ben Campbell (ben@nostrum.com) = wrote: >=20 >> Hi Tim,=20 >>=20 >> (Apologies for the delayed response)=20 >>=20 >> Sorry, but these changes do not resolve my concern. Specifically, I = think implementors reading this draft will create inconsistent of = mixed-OID chains. Commenting specifically:=20 >>=20 >> Section 4.2.1 was changed from saying that the new OID indicates that = the procedures in 4.2.4.4 are to be used to saying that the new OID = =E2=80=9Cdrives the decision=E2=80=9D in step 8 4.2.4.4. =E2=80=9CDrives = the decision=E2=80=9D is vague without details about how the how the = rule in step 8 of 4.2.4.4 actually uses that information. There has been = no change in 4.2.4.4 to address this. Sections 4.2.2.5 and 4.2.2.6 still = say that the new OIDs indicate the procedures in 4.2.4.4 are to be used. = The =E2=80=9Crather than=E2=80=9D clause has been removed, but I don=E2=80= =99t think that changes anything, and it=E2=80=99s still a reasonable = (and likely) interpretation to assume that certificates with the old OID = will follow the old validation policy.=20 >>=20 >> I don=E2=80=99t see how the new text in the abstract changes = anything. (And if it did, I would argue the abstract is the wrong place = to say it.)=20 >>=20 >> I think fixing this would require one of the following changes:=20 >>=20 >> 1) Disallow mixed-OID chains, or=E2=80=A6=20 >>=20 >> 2) The following changes to allow mixed-OID chains:=20 >> - Explicit text that implementations MAY/SHOULD use the new = validation policy even for certs in the chain that do not include the = OID. (Perhaps only if the root cert included it?)=20 >> - Change the description of the OID to say the OID is an input into = the new validation rules, not a discriminator about which rules to use. = (Which, if I understand correctly might remove the point of a new OID in = the first place. Maybe it only matters in the root cert?)=20 >> - Add text to 4.2.4.4 to explain exactly how the rules use the OID as = an input.=20 >>=20 >> Thanks,=20 >>=20 >> Ben.=20 >>=20 >> > On Oct 6, 2017, at 8:36 AM, Tim Bruijnzeels wrote:=20= >> > =20 >> > Dear Ben, Alvaro, others,=20 >> > =20 >> > Please find a new version -09 attached. Not uploaded yet, because I = thought it better to discuss here first and get clarity.=20 >> > =20 >> > With regards to the changes. I understand that the non-normative = text in the abstract and the sections where the new OIDs are introduced = in -08 were inconsistent with the intent (and normative) text in section = 4.2.2.4 to have one validation algorithm that can be used to validate = both current RFC6487 Resource Certificates as well as Resource = Certificates that use the new OIDs introduced here.I hope that this new = version eliminated this ambiguity. Ben, can you please let us know if = this version addresses your concerns?=20 >> > =20 >> > Alvaro, it=E2=80=99s of course your prerogative to take this back = to IETF or WG last call if you feel this confusion was widespread and = let to misinterpretations. For our part I do want to re-state though = that the normative text in 4.2.2.4 was quite explicit, as well as the = deployment considerations section where it=E2=80=99s explicitly = mentioned that this is a per CA choice and a mix of OIDs in a tree is = possible. I also referred to this in my email to the WG when -07 was = published on 3 October 2016. So, it was certainly not our intent to have = any unclarity or inconsistency about this in earlier sections in the = document.=20 >> > =20 >> > Please let me know what you think. If we can proceed, then I can = update this document with the other review comments and upload, and = hopefully get this rolling again. But first I want to make sure that the = issues above are resolved.=20 >> > =20 >> > Kind regards,=20 >> > =20 >> > Tim Bruijnzeels=20 >> > =20 >> > =3D=3D=3D=3D=3D=20 >> > =20 >> > For the impatient, we made changes to the following sections:=20 >> > =20 >> > Abstract=20 >> > =20 >> > This document specifies an alternative to the certificate = validation procedure specified in RFC 6487 that reduces aspects of = operational fragility in the management of certificates in the RPKI, = while retaining essential security features.=20 >> > =20 >> > Where the procedure specified in RFC 6487 requires that Resource = Certificates are rejecting entirely if they are found to over-claim any = resources not contained on the issuing certificate, the validation = process defined here allows an issuing Certificate Authority to chose to = communicate that such Resource Certificates should be accepted for the = intersection of their resources and the issuing certificate.=20 >> > =20 >> > This choice is signalled by form of a set of alternative Object = Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS = Identifiers, and certificate policy for the Resource Public Key = Infrastructure (RFC 6484). It should be noted that in case these OIDs = are not used for any certificate under a Trust Anchor, the validation = procedure defined here has the same outcome as the procedure defined in = RFC 6487=20 >> > =20 >> > Furthermore this document provides an alternative to ROA (RFC = 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication = requested) validation.=20 >> > =20 >> > 4.2.1. Certificate Policy (CP) for use with validation reconsidered = in the Resource PKI (RPKI)=20 >> > =20 >> > ...=20 >> > This alternative Certificate Policy is the same as the Certificate = Policy described in [RFC6484], except that it is used to drive the = decision in step 8 of the validation procedure described in Section = 4.2.4.4.=20 >> > =20 >> > 4.2.2.1. OID for id-pe-ipAddrBlocks-v2=20 >> > =20 >> > This document request an OID for the extension = id-pe-ipAddrBlocks-v2 (id-pe TBD2). This OID MUST only be used in = conjunction with the alternative Certificate Policy OID defined in = Section 4.2.1.=20 >> > =E2=80=A6.=20 >> > =20 >> > 4.2.2.3. OID for id-pe-autonomousSysIds-v2=20 >> > =20 >> > This document request an OID for the extension = id-pe-autonomousSysIds-v2 ( id-pe TBD3). This OID MUST only be used in = conjunction with the alternative Certificate Policy OID defined in = Section 4.2.1.=20 >> > =E2=80=A6.=20 >> > =20 >> > =20 >> > 4.2.2.5. Amended IP Address Delegation Extension Certification Path = Validation=20 >> > =20 >> > Certificate path validation is performed as specified in Section = 4.2.4.4.=20 >> > =20 >> > 4.2.2.6. Amended Autonomous System Identifier Delegation Extension = Certification Path Validation=20 >> > =20 >> > Certificate path validation is performed as specified in Section = 4.2.4.4.=20 >> > =20 >> > =20 >> > =20 >> > =20 >> > =20 >> >> On 22 Sep 2017, at 22:56, Ben Campbell wrote:=20 >> >> =20 >> >>> =20 >> >>> On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels = wrote:=20 >> >>> =20 >> >>> =20 >> >>>> On 18 Sep 2017, at 23:36, Ben Campbell wrote:=20= >> >>>> =20 >> >>>>> =20 >> >>>>> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels = wrote:=20 >> >>>>> =20 >> >>>>> Hi Ben, all,=20 >> >>>>> =20 >> >>>>>> On 15 Sep 2017, at 23:20, Ben Campbell = wrote:=20 >> >>>>>> =20 >> >>>>>> Hi,=20 >> >>>>>> =20 >> >>>>>> See comments inline. I apologize in advance if I am just being = dense, and I cannot claim to be an expert on how one applies a path = validation policy OID in general.=20 >> >>>>>> =20 >> >>>>>> =20 >> >>>>>> Thanks!=20 >> >>>>>> =20 >> >>>>>> Ben.=20 >> >>>>>> =20 >> >>>>>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels = wrote:=20 >> >>>>>>> =20 >> >>>>>>> Hi,=20 >> >>>>>>> =20 >> >>>>>>> Sure. I also proceeded to discuss your and Terry=E2=80=99s = points, but apparently not to the desired level of clarity. Let me try = again here, and tackle both your and Terry=E2=80=99s discuss items since = they are closely related.=20 >> >>>>>>> =20 >> >>>>>>>> Is it legal to mix certificate policies in a given cert = path? The last=20 >> >>>>>>>> paragraph of section 5 implies that you can, but doesn't say = so explicitly.=20 >> >>>>>>> =20 >> >>>>>>> According to this document it is. Section 4.2.2.4 starts with = the following:=20 >> >>>>>>> =20 >> >>>>>>> The following is an amended specification for path validation = to be=20 >> >>>>>>> used in place of section 7.2 of [RFC6487] allowing for the = validation=20 >> >>>>>>> of both certificates following the profile defined in = [RFC6487], as=20 >> >>>>>>> well as certificates following the profile described above.=20= >> >>>>>>> =20 >> >>>>>>> So the intent here is to describe a single validation = algorithm that can be used to validate a chain of old OIDs only (in = which case it=E2=80=99s semantically equivalent to the current spec in = RFC6487), new OIDs only (as described in the example in 4.3), or indeed = a mix - but no example is given on how that works out.=20 >> >>>>>>> =20 >> >>>>>>> =20 >> >>>>>>>> If you _can_ mix policies, what happens if you do? If I read = the rules in 4.2.4.4.=20 >> >>>>>>>> correctly (and it's likely that I am not), if you run into a = cert in the chain=20 >> >>>>>>>> that does not follow this profile, it's likely to give a = null VRS-IP or VRS-AS=20 >> >>>>>>>> value, which would seem to invalidate an certificate further = down the chain=20 >> >>>>>>>> that _does_ follow this policy?=20 >> >>>>>>> =20 >> >>>>>>> =20 >> >>>>>>> The =E2=80=9CValidated Resource Sets=E2=80=9D (VRS-*) are = always calculated, regardless of whether the old or new OIDs are used.=20= >> >>>>>> =20 >> >>>>>> This is where I am confused. The calculation of VRS is = described in this draft in the amendment to the path validation in = section 7.2 of 6487. I assumed that the amended path validation = procedure only applies with the =E2=80=9Cnew=E2=80=9D OID. Is that = incorrect? If so, can you point to the text that states that? (It=E2=80=99= s entirely possible I missed something, or completely misunderstand how = the OIDs are applied. )=20 >> >>>>> =20 >> >>>>> First paragraph of 4.2.2.4:=20 >> >>>>> =20 >> >>>>> "The following is an amended specification for path validation = to be used in place of section 7.2 of [RFC6487]=20 >> >>>>> allowing for the validation of both certificates following the = profile defined in [RFC6487], as well as certificates=20 >> >>>>> following the profile described above."=20 >> >>>>> =20 >> >>>>> So, yes, as far as I am concerned the intent was to have this = cover both the old and new OIDs. Where the algorithm if applied to old = OID only is semantically equivalent to section 7.2 of RFC6487 - or at = least: it has the same outcome.=20 >> >>>>> =20 >> >>>> =20 >> >>>> That intent surprises me, I was under the impression the entire = document was specific to the new OIDs. This seems to be supported by = this text in the abstract:=20 >> >>>> =20 >> >>>> "The use of this updated procedure is signalled by form of a set = of alternative Object Identifiers (OIDs) indicating that the alternative = version of RFC 3779 X.509 Extensions for IP Addresses and AS = Identifiers, and certificate policy for the Resource Public Key = Infrastructure ( RFC 6484) defined in this document should be used.=E2=80=9D= =20 >> >>>> =20 >> >>>> =E2=80=A6 and in the specific case of the certificate validation = policy OID, there is this text in 4.2.1:=20 >> >>>> =20 >> >>>> "This alternative Certificate Policy is the same as the = Certificate Policy described in [=20 >> >>>> RFC6484], except that it indicates that the validation rules = described in=20 >> >>>> Section 4.2.4.4 are to be used.=E2=80=9D=20 >> >>>> =20 >> >>>> If the rules in 4.2.4.4 are used even when that OID is not = present, then I=E2=80=99m confused about what the OID signals in the = first place.=20 >> >>> =20 >> >>> The OIDs are used to drive a decision in the rules described in = 4.2.4.4.=20 >> >>> =3D Old OIDs -> reject over-claim, this has the same result as = section 7.2 in RFC6487=20 >> >>> =3D New OIDs -> warn on over-claim=20 >> >> =20 >> >> Are you suggesting the text =E2=80=9Cshould=E2=80=9D say that, or = =E2=80=9Cdoes=E2=80=9D say that? As written, the OID seems to drive the = selection about whether you use the rules in 4.2.4.4 or not. But I think = you are saying that, if you implement these OIDs, you SHOULD/MAY use the = rules in 4.2.4.4 all the time, but use the OID as an input to those = rules. Is that correct?=20 >> >> =20 >> >> =20 >> >>> =20 >> >>> So as far as clarity goes, it might be better to either leave out = the set regarding the need for the different OIDs in their respective = sections, or say =E2=80=9CThis OID is used to in the decision process of = the validation rules described in 4.2.4.4.=20 >> >> =20 >> >> I=E2=80=99m not sure what you mean by the former. If you go with = the latter, then the rules in 4.2.4.4 will need to be explicit in how = the OID is used in that process.=20 >> >> =20 >> >>> =20 >> >>>>> If this needs to be more explicit I am happy to accept a = suggestion - as an author knowing my own intentions, it=E2=80=99s not = always trivial to see how others would interpret text differently.=20 >> >>>> =20 >> >>>> I=E2=80=99m not sure this is just a matter of clarification. The = text I mention above explicitly says the OID signals the use of the = amended CP. I have to assume that was the working group intent, and what = was understood by people during IETF LC. If that is _not_ the intent, we = would need some degree of consensus to change that text. ( I suspect = that would mean going back to the WG or IETF LC, but I will leave that = to Alvaro to decide.)=20 >> >>>> =20 >> >>> =20 >> >>> It was my assumption that my intent was clear.=20 >> >>> =20 >> >>> But I will accept whatever Alvaro decides on this.=20 >> >>> =20 >> >>> =20 >> >>>> My strictly personal opinion is that it would be _really_ = confusing to have some aspects of the new CP apply even when the new OID = is not used.=20 >> >>> =20 >> >>> The assumption on my part here was that RPs can decide to support = this RFC-to-be and then use section 4.2.4.4 to validate old and new CP = alike.=20 >> >>> =20 >> >>> The process described in 4.2.4.4 when used for old OIDs only has = the same outcome as section 7.2 of RFC 6487. It=E2=80=99s true that = =E2=80=9CValidated Resource Sets=E2=80=9D are not named in RFC6487, but = in a tree where only old OIDs are used one will find that the Validated = Resource Set for a given *valid* certificate always matches the = certificate itself.=20 >> >> =20 >> >> As I mentioned above, if the idea is to always use the rules in = 4.2.4.4, and use the OID to drive decisions _within_ those rules, the = rules need to be updated with the explicit details.=20 >> >> =20 >> >>> =20 >> >>> Thanks=20 >> >>> Tim=20 >> >>> =20 >> >>> =20 >> >>>> =20 >> >>>> Thanks,=20 >> >>>> =20 >> >>>> Ben.=20 >> >=20 From nobody Thu Nov 2 06:23:42 2017 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 45F3113F6C9 for ; Thu, 2 Nov 2017 06:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Y1z4MBAmqjoh for ; Thu, 2 Nov 2017 06:23:33 -0700 (PDT) Received: from mail.lacnic.net.uy (hermes.lacnic.net.uy [IPv6:2001:13c7:7001:4000::8]) by ietfa.amsl.com (Postfix) with ESMTP id 6122913F6FD for ; Thu, 2 Nov 2017 06:23:21 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id 600A416B40542 for ; Thu, 2 Nov 2017 10:23:20 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS0I_8Uy0ItB for ; Thu, 2 Nov 2017 10:23:17 -0300 (UYT) Received: from [54.210.254.221] (ec2-54-210-254-221.compute-1.amazonaws.com [54.210.254.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id A129D16B4084A for ; Thu, 2 Nov 2017 10:23:16 -0300 (UYT) Content-Type: multipart/alternative; boundary="----sinikael-?=_1-15096289963900.36075404076837003" From: Carlos Martinez To: Tim Bruijnzeels Cc: Alvaro Retana , Ben Campbell , Terry Manderson , Chris Morrow , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, sidr chairs , The IESG , sidr@ietf.org In-Reply-To: <902ADA93-8D4B-4D0A-BD9B-F400083CC68E@ripe.net> References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com> <58459EC7-14B4-4F27-929B-3BB9017C48A8@nostrum.com> <467A9EB7-8112-43C3-A4CD-6E51E93B5660@ripe.net> <902ADA93-8D4B-4D0A-BD9B-F400083CC68E@ripe.net> Message-Id: <804e2d6f-c8f0-4357-aad2-bb6d4db50773@lacnic.net> Date: Thu, 02 Nov 2017 10:22:43 -0300 X-Cm-Message-Id: 15096289640201627711172f96b545714c5502d58a524b0259fb1c2404f7f1746190312 X-Cm-Draft-Id: WyJhIiw1LCJkcmFmdF9pZCIsMTUwOTYyODk2MzIxMywidiIsMV0= X-Cm-Tracking-Code: 2.0/1509628963/96f2d3060286ecbab9150cfe7cb38c63/5/5a1d1bdee27635000a29d0998e569e78/c58a12443aff9dd4eb0c5fed46e2454e/33c926a802fa4a0456df798c7f8b3bb6 X-Mailer: Newton MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:23:37 -0000 ------sinikael-?=_1-15096289963900.36075404076837003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree that an in person meeting could help Sent from a mobile device. = Mis disculpas. Enviado desde un dispositivo movil. On Thu, Nov 02, 2017 at = 10:21am, Tim Bruijnzeels < tim@ripe.net [tim@ripe.net] > wrote: Alvaro, Ben, Given that I will meet with my co-authors in person at = IETF100 I would like to take the opportunity to discuss things there with = them in person and then get back to the list. Will both of you be there as = well by chance? I think we could benefit from a chat in person in order to = make updates more efficiently. Tim > On 30 Oct 2017, at 20:45, Alvaro = Retana wrote: > > Tim: > > Hi! > > FWIW, I agree with Ben that the text doesn=E2=80=99t resolve his concerns= , and it doesn=E2=80=99t reflect what you said on the thread. I think you = two are actually saying the same thing (or pretty close), but using = different words. > > I think that at least (+ the specific points made by = Ben below) the text needs to explicitly expand the new Abstract text = throughout the rest of the document, potentially include an example of = mixed OIDs, and talk about the use of the new OIDs in with the old = procedure. Some of these things are sort of implicit already; for example, = using the new OIDs with the old procedure is not specified in = rfc6487=E2=80=A6but explicitly mentioning it in this document won=E2=80=99t= hurt. > > Thanks! > > Alvaro. > > On October 27, 2017 at 5:57:08 PM, Ben = Campbell (ben@nostrum.com) wrote: > >> Hi Tim, >> >> (Apologies for the = delayed response) >> >> Sorry, but these changes do not resolve my concern.= Specifically, I think implementors reading this draft will create = inconsistent of mixed-OID chains. Commenting specifically: >> >> Section 4.2.1 was changed from saying that the new OID indicates that = the procedures in 4.2.4.4 are to be used to saying that the new OID = =E2=80=9Cdrives the decision=E2=80=9D in step 8 4.2.4.4. =E2=80=9CDrives = the decision=E2=80=9D is vague without details about how the how the rule = in step 8 of 4.2.4.4 actually uses that information. There has been no = change in 4.2.4.4 to address this. Sections 4.2.2.5 and 4.2.2.6 still say = that the new OIDs indicate the procedures in 4.2.4.4 are to be used. The = =E2=80=9Crather than=E2=80=9D clause has been removed, but I don=E2=80=99t = think that changes anything, and it=E2=80=99s still a reasonable (and = likely) interpretation to assume that certificates with the old OID will = follow the old validation policy. >> >> I don=E2=80=99t see how the new = text in the abstract changes anything. (And if it did, I would argue the = abstract is the wrong place to say it.) >> >> I think fixing this would = require one of the following changes: >> >> 1) Disallow mixed-OID chains, = or=E2=80=A6 >> >> 2) The following changes to allow mixed-OID chains: >> - Explicit text that implementations MAY/SHOULD use the new validation = policy even for certs in the chain that do not include the OID. (Perhaps = only if the root cert included it?) >> - Change the description of the OID = to say the OID is an input into the new validation rules, not a = discriminator about which rules to use. (Which, if I understand correctly = might remove the point of a new OID in the first place. Maybe it only = matters in the root cert?) >> - Add text to 4.2.4.4 to explain exactly how = the rules use the OID as an input. >> >> Thanks, >> >> Ben. >> >> > On Oct 6, 2017, at 8:36 AM, Tim Bruijnzeels wrote: >> > >> > Dear Ben, Alvaro, others, >> > >> > Please find a new version -09 = attached. Not uploaded yet, because I thought it better to discuss here = first and get clarity. >> > >> > With regards to the changes. I understand = that the non-normative text in the abstract and the sections where the new = OIDs are introduced in -08 were inconsistent with the intent (and = normative) text in section 4.2.2.4 to have one validation algorithm that = can be used to validate both current RFC6487 Resource Certificates as well = as Resource Certificates that use the new OIDs introduced here.I hope that = this new version eliminated this ambiguity. Ben, can you please let us know= if this version addresses your concerns? >> > >> > Alvaro, it=E2=80=99s of= course your prerogative to take this back to IETF or WG last call if you = feel this confusion was widespread and let to misinterpretations. For our = part I do want to re-state though that the normative text in 4.2.2.4 was = quite explicit, as well as the deployment considerations section where = it=E2=80=99s explicitly mentioned that this is a per CA choice and a mix of= OIDs in a tree is possible. I also referred to this in my email to the WG = when -07 was published on 3 October 2016. So, it was certainly not our = intent to have any unclarity or inconsistency about this in earlier = sections in the document. >> > >> > Please let me know what you think. If = we can proceed, then I can update this document with the other review = comments and upload, and hopefully get this rolling again. But first I want= to make sure that the issues above are resolved. >> > >> > Kind regards, >> > >> > Tim Bruijnzeels >> > >> > =3D=3D=3D=3D=3D >> > >> > For the impatient, we made changes to the following sections: >> > >> > Abstract >> > >> > This document specifies an alternative to the = certificate validation procedure specified in RFC 6487 that reduces aspects= of operational fragility in the management of certificates in the RPKI, = while retaining essential security features. >> > >> > Where the procedure = specified in RFC 6487 requires that Resource Certificates are rejecting = entirely if they are found to over-claim any resources not contained on the= issuing certificate, the validation process defined here allows an issuing= Certificate Authority to chose to communicate that such Resource = Certificates should be accepted for the intersection of their resources and= the issuing certificate. >> > >> > This choice is signalled by form of a = set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions = for IP Addresses and AS Identifiers, and certificate policy for the = Resource Public Key Infrastructure (RFC 6484). It should be noted that in = case these OIDs are not used for any certificate under a Trust Anchor, the = validation procedure defined here has the same outcome as the procedure = defined in RFC 6487 >> > >> > Furthermore this document provides an = alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI = Profiles - publication requested) validation. >> > >> > 4.2.1. Certificate = Policy (CP) for use with validation reconsidered in the Resource PKI (RPKI) >> > >> > ... >> > This alternative Certificate Policy is the same as the = Certificate Policy described in [RFC6484], except that it is used to drive = the decision in step 8 of the validation procedure described in Section 4.2= .4.4. >> > >> > 4.2.2.1. OID for id-pe-ipAddrBlocks-v2 >> > >> > This document request an OID for the extension id-pe-ipAddrBlocks-v2 = (id-pe TBD2). This OID MUST only be used in conjunction with the = alternative Certificate Policy OID defined in Section 4.2.1. >> > =E2=80=A6. >> > >> > 4.2.2.3. OID for id-pe-autonomousSysIds-v2 >> > >> > This document request an OID for the extension = id-pe-autonomousSysIds-v2 ( id-pe TBD3). This OID MUST only be used in = conjunction with the alternative Certificate Policy OID defined in Section = 4.2.1. >> > =E2=80=A6. >> > >> > >> > 4.2.2.5. Amended IP Address = Delegation Extension Certification Path Validation >> > >> > Certificate path validation is performed as specified in Section 4.2.4= .4. >> > >> > 4.2.2.6. Amended Autonomous System Identifier Delegation = Extension Certification Path Validation >> > >> > Certificate path = validation is performed as specified in Section 4.2.4.4. >> > >> > >> > >> > >> > >> >> On 22 Sep 2017, at 22:56, Ben Campbell wrote: >> >> >> >>> >> >>> On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels = wrote: >> >>> >> >>> >> >>>> On 18 Sep 2017, at 23:36, Ben Campbell = wrote: >> >>>> >> >>>>> >> >>>>> On Sep 18, 2017, at 8:15= AM, Tim Bruijnzeels wrote: >> >>>>> >> >>>>> Hi Ben, all, >> >>>>> >> >>>>>> On 15 Sep 2017, at 23:20, Ben Campbell = wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> See comments inline. I = apologize in advance if I am just being dense, and I cannot claim to be an = expert on how one applies a path validation policy OID in general. >> >>>>>> >> >>>>>> >> >>>>>> Thanks! >> >>>>>> >> >>>>>> Ben. >> >>>>>> >> >>>>>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels = wrote: >> >>>>>>> >> >>>>>>> Hi, >> >>>>>>> >> >>>>>>> Sure. I also = proceeded to discuss your and Terry=E2=80=99s points, but apparently not to= the desired level of clarity. Let me try again here, and tackle both your = and Terry=E2=80=99s discuss items since they are closely related. >> >>>>>>> >> >>>>>>>> Is it legal to mix certificate policies in a given = cert path? The last >> >>>>>>>> paragraph of section 5 implies that you can= , but doesn't say so explicitly. >> >>>>>>> >> >>>>>>> According to this = document it is. Section 4.2.2.4 starts with the following: >> >>>>>>> >> >>>>>>> The following is an amended specification for path validation to= be >> >>>>>>> used in place of section 7.2 of [RFC6487] allowing for the = validation >> >>>>>>> of both certificates following the profile defined in= [RFC6487], as >> >>>>>>> well as certificates following the profile = described above. >> >>>>>>> >> >>>>>>> So the intent here is to describe a = single validation algorithm that can be used to validate a chain of old = OIDs only (in which case it=E2=80=99s semantically equivalent to the = current spec in RFC6487), new OIDs only (as described in the example in 4.= 3), or indeed a mix - but no example is given on how that works out. >> >>>>>>> >> >>>>>>> >> >>>>>>>> If you _can_ mix policies, what happens = if you do? If I read the rules in 4.2.4.4. >> >>>>>>>> correctly (and it's = likely that I am not), if you run into a cert in the chain >> >>>>>>>> that does not follow this profile, it's likely to give a null = VRS-IP or VRS-AS >> >>>>>>>> value, which would seem to invalidate an = certificate further down the chain >> >>>>>>>> that _does_ follow this = policy? >> >>>>>>> >> >>>>>>> >> >>>>>>> The =E2=80=9CValidated Resource = Sets=E2=80=9D (VRS-*) are always calculated, regardless of whether the old = or new OIDs are used. >> >>>>>> >> >>>>>> This is where I am confused. The = calculation of VRS is described in this draft in the amendment to the path = validation in section 7.2 of 6487. I assumed that the amended path = validation procedure only applies with the =E2=80=9Cnew=E2=80=9D OID. Is = that incorrect? If so, can you point to the text that states that? = (It=E2=80=99s entirely possible I missed something, or completely = misunderstand how the OIDs are applied. ) >> >>>>> >> >>>>> First paragraph= of 4.2.2.4: >> >>>>> >> >>>>> "The following is an amended specification = for path validation to be used in place of section 7.2 of [RFC6487] >> >>>>> allowing for the validation of both certificates following the = profile defined in [RFC6487], as well as certificates >> >>>>> following the profile described above." >> >>>>> >> >>>>> So, yes, as far as I am concerned the intent was to have this = cover both the old and new OIDs. Where the algorithm if applied to old OID = only is semantically equivalent to section 7.2 of RFC6487 - or at least: it= has the same outcome. >> >>>>> >> >>>> >> >>>> That intent surprises me, I= was under the impression the entire document was specific to the new OIDs.= This seems to be supported by this text in the abstract: >> >>>> >> >>>> "The use of this updated procedure is signalled by form of a set of= alternative Object Identifiers (OIDs) indicating that the alternative = version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, = and certificate policy for the Resource Public Key Infrastructure ( RFC = 6484) defined in this document should be used.=E2=80=9D >> >>>> >> >>>> =E2=80=A6 and in the specific case of the certificate validation = policy OID, there is this text in 4.2.1: >> >>>> >> >>>> "This alternative = Certificate Policy is the same as the Certificate Policy described in [ >> >>>> RFC6484], except that it indicates that the validation rules = described in >> >>>> Section 4.2.4.4 are to be used.=E2=80=9D >> >>>> >> >>>> If the rules in 4.2.4.4 are used even when that OID is not present,= then I=E2=80=99m confused about what the OID signals in the first place. >> >>> >> >>> The OIDs are used to drive a decision in the rules described = in 4.2.4.4. >> >>> =3D Old OIDs -> reject over-claim, this has the same = result as section 7.2 in RFC6487 >> >>> =3D New OIDs -> warn on over-claim >> >> >> >> Are you suggesting the text =E2=80=9Cshould=E2=80=9D say that, = or =E2=80=9Cdoes=E2=80=9D say that? As written, the OID seems to drive the = selection about whether you use the rules in 4.2.4.4 or not. But I think = you are saying that, if you implement these OIDs, you SHOULD/MAY use the = rules in 4.2.4.4 all the time, but use the OID as an input to those rules. = Is that correct? >> >> >> >> >> >>> >> >>> So as far as clarity goes, it = might be better to either leave out the set regarding the need for the = different OIDs in their respective sections, or say =E2=80=9CThis OID is = used to in the decision process of the validation rules described in 4.2.4.= 4. >> >> >> >> I=E2=80=99m not sure what you mean by the former. If you go = with the latter, then the rules in 4.2.4.4 will need to be explicit in how = the OID is used in that process. >> >> >> >>> >> >>>>> If this needs to be = more explicit I am happy to accept a suggestion - as an author knowing my = own intentions, it=E2=80=99s not always trivial to see how others would = interpret text differently. >> >>>> >> >>>> I=E2=80=99m not sure this is = just a matter of clarification. The text I mention above explicitly says = the OID signals the use of the amended CP. I have to assume that was the = working group intent, and what was understood by people during IETF LC. If = that is _not_ the intent, we would need some degree of consensus to change = that text. ( I suspect that would mean going back to the WG or IETF LC, but= I will leave that to Alvaro to decide.) >> >>>> >> >>> >> >>> It was my assumption that my intent was clear. >> >>> >> >>> But I will accept whatever Alvaro decides on this. >> >>> >> >>> >> >>>> My strictly personal opinion is that it would be _really_ confusing= to have some aspects of the new CP apply even when the new OID is not used= . >> >>> >> >>> The assumption on my part here was that RPs can decide to = support this RFC-to-be and then use section 4.2.4.4 to validate old and new= CP alike. >> >>> >> >>> The process described in 4.2.4.4 when used for old= OIDs only has the same outcome as section 7.2 of RFC 6487. It=E2=80=99s = true that =E2=80=9CValidated Resource Sets=E2=80=9D are not named in = RFC6487, but in a tree where only old OIDs are used one will find that the = Validated Resource Set for a given *valid* certificate always matches the = certificate itself. >> >> >> >> As I mentioned above, if the idea is to = always use the rules in 4.2.4.4, and use the OID to drive decisions = _within_ those rules, the rules need to be updated with the explicit = details. >> >> >> >>> >> >>> Thanks >> >>> Tim >> >>> >> >>> >> >>>> >> >>>> Thanks, >> >>>> >> >>>> Ben. >> > ------sinikael-?=_1-15096289963900.36075404076837003 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I agree that an in person meeting = could help


Sent from a mobile device. = Mis disculpas.  
Enviado desde un dispositivo movil.
=
On Thu, Nov 02, = 2017 at 10:21am, Tim Bruijnzeels <tim@ripe.net> wrote:

Alvaro, Ben,

Given that I will meet with my = co-authors in person at IETF100 I would like to take the opportunity to = discuss things there with them in person and then get back to the list. = Will both of you be there as well by chance? I think we could benefit from = a chat in person in order to make updates more efficiently.=

Tim

> On 30 Oct 2017, at 20:45, Alvaro Retana = <aretana.ietf@gmail.com> wrote:
>=20
> Tim:
>=20
> Hi!
>=20
> FWIW, I agree with Ben that = the text doesn=E2=80=99t resolve his concerns, and it doesn=E2=80=99t = reflect what you said on the thread.  I think you two are actually = saying the same thing (or pretty close), but using different words.=  =20
>=20
> I think that at least (+ the specific = points made by Ben below) the text needs to explicitly expand the new = Abstract text throughout the rest of the document, potentially include an = example of mixed OIDs, and talk about the use of the new OIDs in with the = old procedure.  Some of these things are sort of implicit already; for= example, using the new OIDs with the old procedure is not specified in = rfc6487=E2=80=A6but explicitly mentioning it in this document won=E2=80=99t= hurt.
>=20
> Thanks!
>=20
> Alvaro.
>=20
> On October 27, 2017 at 5:57:08 PM, Ben Campbell = (ben@nostrum.com) wrote:
>=20
>> Hi Tim,=20
>>=20
>> (Apologies for the delayed response)=20
>>=20
>> Sorry, but these changes do not resolve my = concern. Specifically, I think implementors reading this draft will create = inconsistent of mixed-OID chains. Commenting specifically:=20
>>=20
>> Section 4.2.1 was changed from saying that the = new OID indicates that the procedures in 4.2.4.4 are to be used to saying = that the new OID =E2=80=9Cdrives the decision=E2=80=9D in step 8 4.2.4.4. = =E2=80=9CDrives the decision=E2=80=9D is vague without details about how = the how the rule in step 8 of 4.2.4.4 actually uses that information. There= has been no change in 4.2.4.4 to address this. Sections 4.2.2.5 and 4.2.2.= 6 still say that the new OIDs indicate the procedures in 4.2.4.4 are to be = used. The =E2=80=9Crather than=E2=80=9D clause has been removed, but I = don=E2=80=99t think that changes anything, and it=E2=80=99s still a = reasonable (and likely) interpretation to assume that certificates with the= old OID will follow the old validation policy.=20
>>=20
>> I don=E2=80=99t see how the new text in the abstract changes = anything. (And if it did, I would argue the abstract is the wrong place to = say it.)=20
>>=20
>> I think fixing this would = require one of the following changes:=20
>>=20
>> 1) Disallow mixed-OID chains, or=E2=80=A6=20
>>=20
>> 2) The following changes to allow mixed-OID chains:=20
>> - Explicit text that implementations MAY/SHOULD use the new = validation policy even for certs in the chain that do not include the OID. = (Perhaps only if the root cert included it?)=20
>> - Change the description of the OID to say the OID is an input = into the new validation rules, not a discriminator about which rules to use= . (Which, if I understand correctly might remove the point of a new OID in = the first place. Maybe it only matters in the root cert?)=20
>> - Add text to 4.2.4.4 to explain exactly how the rules use the OID= as an input.=20
>>=20
>> Thanks,= =20
>>=20
>> Ben.=20
>>=20
>> > On Oct 6, 2017, at 8:36 AM, Tim Bruijnzeels <tim@ripe.= net> wrote:=20
>> > =20
>> > Dear Ben, = Alvaro, others,=20
>> > =20
>> > Please find a new version -09 attached. Not uploaded yet, = because I thought it better to discuss here first and get clarity.=20
>> > =20
>> > With regards to the changes. I = understand that the non-normative text in the abstract and the sections = where the new OIDs are introduced in -08 were inconsistent with the intent = (and normative) text in section 4.2.2.4 to have one validation algorithm = that can be used to validate both current RFC6487 Resource Certificates as = well as Resource Certificates that use the new OIDs introduced here.I hope = that this new version eliminated this ambiguity. Ben, can you please let us= know if this version addresses your concerns?=20
>> > =20
>> > Alvaro, it=E2=80=99s of course = your prerogative to take this back to IETF or WG last call if you feel this= confusion was widespread and let to misinterpretations. For our part I do = want to re-state though that the normative text in 4.2.2.4 was quite = explicit, as well as the deployment considerations section where = it=E2=80=99s explicitly mentioned that this is a per CA choice and a mix of= OIDs in a tree is possible. I also referred to this in my email to the WG = when -07 was published on 3 October 2016. So, it was certainly not our = intent to have any unclarity or inconsistency about this in earlier = sections in the document.=20
>> > =20
>> > Please let me know what you think. If we can proceed, then I = can update this document with the other review comments and upload, and = hopefully get this rolling again. But first I want to make sure that the = issues above are resolved.=20
>> > =20
>> > Kind regards,=20
>> > =20
>> > Tim Bruijnzeels=20
>> > =20
>> > =3D=3D=3D=3D=3D=20
>> > =20
>> > For the impatient, we made changes to the following = sections:=20
>> > =20
>> > = Abstract=20
>> > =20
>> > This document = specifies an alternative to the certificate validation procedure specified = in RFC 6487 that reduces aspects of operational fragility in the management= of certificates in the RPKI, while retaining essential security features.= =20
>> > =20
>> > Where the procedure = specified in RFC 6487 requires that Resource Certificates are rejecting = entirely if they are found to over-claim any resources not contained on the= issuing certificate, the validation process defined here allows an issuing= Certificate Authority to chose to communicate that such Resource = Certificates should be accepted for the intersection of their resources and= the issuing certificate.=20
>> > =20
>> > This choice is signalled by form of a set of alternative = Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and= AS Identifiers, and certificate policy for the Resource Public Key = Infrastructure (RFC 6484). It should be noted that in case these OIDs are = not used for any certificate under a Trust Anchor, the validation procedure= defined here has the same outcome as the procedure defined in RFC = 6487=20
>> > =20
>> > Furthermore this = document provides an alternative to ROA (RFC 6482), and BGPSec Router = Certificate (BGPSec PKI Profiles - publication requested) validation.= =20
>> > =20
>> > 4.2.1. Certificate = Policy (CP) for use with validation reconsidered in the Resource PKI = (RPKI)=20
>> > =20
>> > ...=20
>> > This alternative Certificate Policy is the same as the = Certificate Policy described in [RFC6484], except that it is used to drive = the decision in step 8 of the validation procedure described in Section 4.2= .4.4.=20
>> > =20
>> > 4.2.2.1. OID for = id-pe-ipAddrBlocks-v2=20
>> > =20
>> > This document request an OID for the extension = id-pe-ipAddrBlocks-v2 (id-pe TBD2). This OID MUST only be used in = conjunction with the alternative Certificate Policy OID defined in Section = 4.2.1.=20
>> > =E2=80=A6.=20
>> > =20
>> > 4.2.2.3. OID for id-pe-autonomousSysIds-v2=20
>> > =20
>> > This document request an OID for = the extension id-pe-autonomousSysIds-v2 ( id-pe TBD3). This OID MUST only = be used in conjunction with the alternative Certificate Policy OID defined = in Section 4.2.1.=20
>> > =E2=80=A6.=20
>> > =20
>> > =20
>> > 4.2.2.5. Amended IP Address Delegation Extension = Certification Path Validation=20
>> > =20
>> > Certificate path validation is performed as specified in = Section 4.2.4.4.=20
>> > =20
>> > 4.2.2.6. Amended Autonomous System Identifier Delegation = Extension Certification Path Validation=20
>> > =20
>> > Certificate path validation is performed as specified in = Section 4.2.4.4.=20
>> > =20
>> > <draft-ietf-sidr-rpki-validation-reconsidered-09.= txt>=20
>> > =20
>> > =20
>> > =20
>> >> On 22 Sep 2017, at 22:56, Ben= Campbell <ben@nostrum.com> wrote:=20
>> = >> =20
>> >>> =20
>> >>> On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels = <tim@ripe.net> wrote:=20
>> >>> =20
>> >>> =20
>> >>>> On 18 Sep = 2017, at 23:36, Ben Campbell <ben@nostrum.com> wrote:=20
>> >>>> =20
>> >>>>> = =20
>> >>>>> On Sep 18, 2017, at 8:15 AM, Tim = Bruijnzeels <tim@ripe.net> wrote:=20
>> = >>>>> =20
>> >>>>> Hi Ben, = all,=20
>> >>>>> =20
>> >>>>>> On 15 Sep 2017, at 23:20, Ben Campbell = <ben@nostrum.com> wrote:=20
>> >>>>>>&nb= sp;=20
>> >>>>>> Hi,=20
>> >>>>>> =20
>> = >>>>>> See comments inline. I apologize in advance if I = am just being dense, and I cannot claim to be an expert on how one applies = a path validation policy OID in general.=20
>> = >>>>>> =20
>> >>>>>>&nb= sp;=20
>> >>>>>> Thanks!=20
>> >>>>>> =20
>> = >>>>>> Ben.=20
>> >>>>>>&nbs= p;=20
>> >>>>>>> On Sep 14, 2017, at 7:00 = AM, Tim Bruijnzeels <tim@ripe.net> wrote:=20
>> >>>>>>> =20
>> >>>>>>> Hi,=20
>> = >>>>>>> =20
>> = >>>>>>> Sure. I also proceeded to discuss your and = Terry=E2=80=99s points, but apparently not to the desired level of clarity.= Let me try again here, and tackle both your and Terry=E2=80=99s discuss = items since they are closely related.=20
>> = >>>>>>> =20
>> = >>>>>>>> Is it legal to mix certificate policies in= a given cert path? The last=20
>> >>>>>>>&= gt; paragraph of section 5 implies that you can, but doesn't say so = explicitly.=20
>> >>>>>>> =20
>> >>>>>>> According to this document it is. = Section 4.2.2.4 starts with the following:=20
>> = >>>>>>> =20
>> = >>>>>>> The following is an amended specification for = path validation to be=20
>> >>>>>>> used in= place of section 7.2 of [RFC6487] allowing for the validation=20
>> >>>>>>> of both certificates following the = profile defined in [RFC6487], as=20
>> >>>>>>&= gt; well as certificates following the profile described above.=20
>> >>>>>>> =20
>> >>>>>>> So the intent here is to describe a = single validation algorithm that can be used to validate a chain of old = OIDs only (in which case it=E2=80=99s semantically equivalent to the = current spec in RFC6487), new OIDs only (as described in the example in 4.= 3), or indeed a mix - but no example is given on how that works out.= =20
>> >>>>>>> =20
>> >>>>>>> =20
>> >>>>>>>> If you _can_ mix policies, what = happens if you do? If I read the rules in 4.2.4.4.=20
>> >>>>>>>> correctly (and it's likely that I= am not), if you run into a cert in the chain=20
>> >>>>>>>> that does not follow this profile= , it's likely to give a null VRS-IP or VRS-AS=20
>> >>>>>>>> value, which would seem to = invalidate an certificate further down the chain=20
>> >>>>>>>> that _does_ follow this policy?= =20
>> >>>>>>> =20
>> >>>>>>> =20
>> >>>>>>> The =E2=80=9CValidated Resource = Sets=E2=80=9D (VRS-*) are always calculated, regardless of whether the old = or new OIDs are used.=20
>> >>>>>> =20 >> >>>>>> This is where I am confused. The = calculation of VRS is described in this draft in the amendment to the path = validation in section 7.2 of 6487. I assumed that the amended path = validation procedure only applies with the =E2=80=9Cnew=E2=80=9D OID. Is = that incorrect? If so, can you point to the text that states that? = (It=E2=80=99s entirely possible I missed something, or completely = misunderstand how the OIDs are applied. )=20
>> = >>>>> =20
>> >>>>> First = paragraph of 4.2.2.4:=20
>> >>>>> =20
>> >>>>> "The following is an amended specification = for path validation to be used in place of section 7.2 of [RFC6487]=20
>> >>>>> allowing for the validation of both = certificates following the profile defined in [RFC6487], as well as = certificates=20
>> >>>>> following the profile = described above."=20
>> >>>>> =20
>> >>>>> So, yes, as far as I am concerned the intent = was to have this cover both the old and new OIDs. Where the algorithm if = applied to old OID only is semantically equivalent to section 7.2 of = RFC6487 - or at least: it has the same outcome.=20
>> >>>>> =20
>> = >>>> =20
>> >>>> That intent = surprises me, I was under the impression the entire document was specific = to the new OIDs. This seems to be supported by this text in the = abstract:=20
>> >>>> =20
>> >>>> "The use of this updated procedure is signalled = by form of a set of alternative Object Identifiers (OIDs) indicating that = the alternative version of RFC 3779 X.509 Extensions for IP Addresses and = AS Identifiers, and certificate policy for the Resource Public Key = Infrastructure ( RFC 6484) defined in this document should be used.= =E2=80=9D=20
>> >>>> =20
>> >>>> =E2=80=A6 and in the specific case of the = certificate validation policy OID, there is this text in 4.2.1:=20
>> >>>> =20
>> >>>> "This = alternative Certificate Policy is the same as the Certificate Policy = described in [=20
>> >>>> RFC6484], except that it = indicates that the validation rules described in=20
>> >>>> Section 4.2.4.4 are to be used.=E2=80=9D=20
>> >>>> =20
>> >>>> If the = rules in 4.2.4.4 are used even when that OID is not present, then = I=E2=80=99m confused about what the OID signals in the first place.=20
>> >>> =20
>> >>> The OIDs are used= to drive a decision in the rules described in 4.2.4.4.=20
>> >>> =3D Old OIDs -> reject over-claim, this has the = same result as section 7.2 in RFC6487=20
>> >>> =3D New= OIDs -> warn on over-claim=20
>> >> =20
>> >> Are you suggesting the text =E2=80=9Cshould=E2=80=9D say = that, or =E2=80=9Cdoes=E2=80=9D say that? As written, the OID seems to = drive the selection about whether you use the rules in 4.2.4.4 or not. But = I think you are saying that, if you implement these OIDs, you SHOULD/MAY = use the rules in 4.2.4.4 all the time, but use the OID as an input to those= rules. Is that correct?=20
>> >> =20
>> >> =20
>> >>> =20
>> >>> So as far as clarity goes, it might be better to = either leave out the set regarding the need for the different OIDs in their= respective sections, or say =E2=80=9CThis OID is used to in the decision = process of the validation rules described in 4.2.4.4.=20
>> >> =20
>> >> I=E2=80=99m not sure what= you mean by the former. If you go with the latter, then the rules in 4.2.4= .4 will need to be explicit in how the OID is used in that process.=20
>> >> =20
>> >>> =20
>> >>>>> If this needs to be more explicit I am happy = to accept a suggestion - as an author knowing my own intentions, = it=E2=80=99s not always trivial to see how others would interpret text = differently.=20
>> >>>> =20
>> >>>> I=E2=80=99m not sure this is just a matter of = clarification. The text I mention above explicitly says the OID signals the= use of the amended CP. I have to assume that was the working group intent,= and what was understood by people during IETF LC. If that is _not_ the = intent, we would need some degree of consensus to change that text. ( I = suspect that would mean going back to the WG or IETF LC, but I will leave = that to Alvaro to decide.)=20
>> >>>> =20
>> >>> =20
>> >>> It was my = assumption that my intent was clear.=20
>> = >>> =20
>> >>> But I will accept whatever= Alvaro decides on this.=20
>> >>> =20
>> >>> =20
>> >>>> My strictly = personal opinion is that it would be _really_ confusing to have some = aspects of the new CP apply even when the new OID is not used.=20
>> >>> =20
>> >>> The assumption on= my part here was that RPs can decide to support this RFC-to-be and then = use section 4.2.4.4 to validate old and new CP alike.=20
>> >>> =20
>> >>> The process = described in 4.2.4.4 when used for old OIDs only has the same outcome as = section 7.2 of RFC 6487. It=E2=80=99s true that =E2=80=9CValidated Resource= Sets=E2=80=9D are not named in RFC6487, but in a tree where only old OIDs = are used one will find that the Validated Resource Set for a given *valid* = certificate always matches the certificate itself.=20
>> >> =20
>> >> As I mentioned above, if = the idea is to always use the rules in 4.2.4.4, and use the OID to drive = decisions _within_ those rules, the rules need to be updated with the = explicit details.=20
>> >> =20
>> >>> =20
>> >>> Thanks=20
>> >>> Tim=20
>> >>> =20
>> >>> =20
>> >>>> =20
>> >>>> Thanks,=20
>> >>>> = =20
>> >>>> Ben.=20
>> >=20

------sinikael-?=_1-15096289963900.36075404076837003-- From nobody Sun Nov 5 18:25:40 2017 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 E061013FC01; Sun, 5 Nov 2017 18:25:38 -0800 (PST) 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, 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 WTPEl-kyThVd; Sun, 5 Nov 2017 18:25:35 -0800 (PST) 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 30BF513FAD7; Sun, 5 Nov 2017 18:25:35 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A36C428B003B; Sun, 5 Nov 2017 21:25:33 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 7B7C61F8036; Sun, 5 Nov 2017 21:25:32 -0500 (EST) Content-Type: multipart/mixed; boundary="Apple-Mail=_B650AB11-8314-4AEC-8E6B-78E1EF5C4751" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> Date: Sun, 5 Nov 2017 21:25:32 -0500 Cc: Sandra Murphy , Christopher Morrow , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org, sidr list Message-Id: <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 02:25:39 -0000 --Apple-Mail=_B650AB11-8314-4AEC-8E6B-78E1EF5C4751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m attaching some comments and questions I found in the -14 = version. =E2=80=94Sandy --Apple-Mail=_B650AB11-8314-4AEC-8E6B-78E1EF5C4751 Content-Disposition: attachment; filename=draft-ietf-sidr-rtr-keying-14.mycomments.rtf Content-Type: text/rtf; name="draft-ietf-sidr-rtr-keying-14.mycomments.rtf" Content-Transfer-Encoding: quoted-printable {\rtf1\ansi\ansicpg1252\cocoartf1404\cocoasubrtf470 {\fonttbl\f0\fmodern\fcharset0 Courier;\f1\fnil\fcharset0 = Menlo-Regular;} = {\colortbl;\red255\green255\blue255;\red0\green0\blue233;\red66\green1\blu= e120;} \margl1440\margr1440\vieww16220\viewh17060\viewkind0 = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \f0\fs24 \cf0 Points that might get lost in the long detailed list that = follows:\ \ 1. RFC4271 (and RFC6286) and RFC8209 use the term \'93BGP = Identifier\'94. The main text says RouterID and the Appendix B says = \'93serial number\'94. I believe both are talking about what RFC8209 = calls the \'93BGP Identifier\'94. Most of the tech sites say router ID = or router-id or routerid or RID or some such. But I think consistency = with the referenced text would be good.\ \ 2. I was initially confused by the text in various places that talks = about the operator adding the AS and RouterID (sic) and sends to the CA. = I thought that meant the operator adds those to the CSR, which would be = hard since the CSR is signed. This occurs a couple of places. I = suggest a sentence early on that says the router certificate includes = the AS and router identifier but the CSR does not include such fields, = so the operator must include the AS and routerID when it sends the CSR = to the CA.\ \ 3. \'93corresponds\'94 - there are several places that say the = certificate must be validated to prove that the public key corresponds = with the private key. The main body does not say how that = correspondence is validated. The appendix suggests that the operator = could validate the signature on the CSR with the returned router cert in = order to validate the key. (a) When the operator generated the = public/private key pair, why not just do a comparison to the generated = public key, presuming it was retained? (b) When the operator passed the = CSR generated by the router to the CA, why not validate the public key = before sending it to the CA? The public key in the returned router = certificate could subsequently be validated by a comparison, presuming = the public key was retained. (c) When the router is supposed to = validate the public key of the router cert it receives, and the operator = generated the public/private key pair, it does not have a copy of the = CSR to validate the correspondence. Took me a bit to realize the router = could sign just any old bit of bytes and then validate the signature = with the received router cert. Right?\ \ 4. \'93corresponds\'94 again - there\'92s no mention of a router = verifying that the router cert it receives has an AS that is configured = on the router. There are lots of other checks and double checks - why = not this one? And if the router has multiple ASs and multiple CSRs have = been generated (either by the router or by the operator), then the = router uses the received router certificate to associate the AS with the = public/private key pair, so it knows which private key to use over which = session. Right?\ \ 5. Section 8 on \'93\expnd0\expndtw0\kerning0 Advanced Deployment Scenarios\'94\kerning1\expnd0\expndtw0 talks about = routers that already have pre-installed keys (with mentions of types of = crypto that are not known to me, and I did not dig up the refs, so I = might be missing something here). The first paragraph talks about = \'93pre-installed key material\'94. I could understand why these = pre-installed keys might be useful in authenticating the router directly = to the CA. The \'93burdens\'94 1 and 2 also talk abut \'93key = material\'94. It did not look to me like the \'93key material\'94 in 1 = and 2 are talking about these \'93pre-installed\'94 keys. But I admit = to being very confused by the way the term is used.\ \ 6. Section 5.2.1 is titled \'94\expnd0\expndtw0\kerning0 Using PKCS#8 to Transfer Public Key\kerning1\expnd0\expndtw0 \'94. The = text talks about using PKCS #8 in RFC5958, which allows for including = both the public and private key. But the text of that section is = talking about using PKCS #8 to transmit the private key to the router. = I presume the title should be \expnd0\expndtw0\kerning0 Using PKCS#8 to Transfer Private Key\kerning1\expnd0\expndtw0 \ \ 7. There is an early assumption that all the communication between the = operator and the router is over a protected channel. Section 5.2.1 = suggests using a CMS SignedData to transmit the PKCS#8. RFC5958 = suggests several different \'93CMS protecting content types\'94 for the = PKCS#8 - EncryptedData, EnvelopedData, etc. I presume that the = encrypted versions are not used here because the protected channel = ensures confidentiality. So (a) Appendix A talks about the key strength = to be used for the different crypto algorithms (encryption, key = exchange, \'85). That\'92s a big hint that the channel should provide = the related security protections. I think it would be good to = explicitly state the protections the protected channel must provide: = \'93The protected channel must provide confidentiality, authentication, = integrity and replay protection\'94. (b) if the protected channel = provides authentication and integrity, why is the protection of the CMS = SignedData needed? One possible reason follows -> (c) The AS EE = certificate has an AS extension, not an IP extension, I presume. So the = AS EE certificate would be a second way for the router to associate a = private key with an AS and an appropriate BGP session (see my comment 3c = above). But this applies only when the operator generated the = public/private key pair.\ \ 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines = several types of content, e.g., signed-data, \expnd0\expndtw0\kerning0 enveloped-data, signed-and-enveloped-data, etc. Is there any reason to = specify which type? Is it operator choice?\ \ 9. The term \'93operator\'94 is used to talk about carbon-based units = (who are forgetful), ISP organizations (who peer with other operators), = ASs (who have an AS EE certificates) and management system stations = (that receive CSRs from the router). It was a bit unsettling, but after = multiple reads through I\'92m getting used to it. I\'92m not sure I = could suggest a term that would fit all those uses. Perhaps network = operators (the ones with DNA) identify personally with all those uses = and think of their person in all cases. \'93I am the AS\'94, \'93I am = the peering entity\'94, \'93I am the management of the network\'94, = etc.\ \ 10. I do not understand the last two paragraphs of section 7 at the = bottom of page 6. It sounds to me like they are out of place, like they = belong elsewhere in the text.\ \ 11. There are some occurrences of \'93must\'94 and only a few of = \'93MUST\'94 - the draft is standards track, so how much of the = described behaviors are mandatory?\ \ 12. Some consistency nits - PKCS sometimes followed by a space, = sometimes not. protected channel, secure channel, communications = channel, protected session, SSH session, . . . \ \ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ \ OK, so on to the detailed comments, sequentially through the document\ \ p3, section 1:\ \ \pard\pardeftab720\partightenfactor0 \cf0 two methods to provision new and existing routers. The methods\ described involve the operator configuring the two end points and\ acting as the intermediary.\ \ What are the two endpoints? The router and the management station? The = router and the CA? I can imagine the operator configuring the = management station, but not the CA. I can imagine the operator acting = as the intermediary between the router and the CA, but not between the = router and the management station.\ \ p3, section 1: (nit)\ \ \fs26 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc8208"}}{\fldrslt \cf2 \ul \ulc2 = RFC8208}}] \fs24 \ \fs26 specifies the algorithms used to generate the signature.\ \fs24 \ If I read correctly, \'93the\'94 signature in this text would be the = signature on the PKCS#10. \ \ suggest:\ \ \fs26 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc8208"}}{\fldrslt \cf2 \ul \ulc2 = RFC8208}}] \fs24 \ \fs26 specifies the algorithms used to generate the PKCS#10 = signature. \fs24 \ \ \ p4, section 2\ \ See \cf3 \ul \ulc3 Appendix A\cf0 \ulnone = for security considerations\ for this channel.\ \ I think it is important to say what security protection are required for = this protected channel.\ Appendix A talks about the strength of the key used in the various = crypto algorithms. I think a\ sentence something like the following would be useful here or in = Appendix A.\ \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \'93The protected channel must provide = confidentiality, authentication, integrity\'94 and replay = protection.\'94\expnd0\expndtw0\kerning0 \ \pard\pardeftab720\partightenfactor0 \cf0 \ p4, section 4 (nit)\ \ appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.\ \ suggest:\ \ appropriate RPKI Trust Anchor Certificate (TA Cert) in the router.\ or\ appropriate RPKI Trust Anchor\'92s Certificate (TA Cert) in the = router.\ \ p4, section 4\ \ The operator also configures the Autonomous System (AS) number to be\ used in the generated router certificate. This may be the sole AS\ configured on the router, or an operator choice if the router is\ configured with multiple ASs.\ \ There\'92s a hint here that the operator configures the router to = generate just one router certificate.\ RFC8209 allows the router certificate to have one or more ASs, but = recommends that there be multiple router certificates with one AS each. = Does this paragraph intend to limit a router to one router certificate = or just to limit the router to one AS per router certificate? I have = questions later about what happens if the router wants a router = certificate for each of multiple ASs.\ \ Perhaps \'93A router with multiple ASs can be configured with multiple = router certificates\'94, maybe also \'93by following the process of this = document for reach desired certificate\'94.\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 The operator configures or extracts from the router the = BGP RouterID\ \ RFC4271 and RFC8209 say \'93BGP Identifier\'94. OSPF uses RouterID, and = lots of C/J commands use RouterID, or router-id, or router id, or RID, = or . . . But consistency with the referenced specs would a good thing. \fs24 \ \ p4, section 5\ \ I think it would be great to add a sentence here explaining that the = PKCS#10 (CSR) format does not include the AS and RouterID (sic). = Therefore, the operator must transmit the AS and RouterID (sic) as well = when it sends the CSR to the CA. \ \ That sentence applies to both the router generated keys and the operator = generated keys, so maybe it could go here.\ \ The PKCS#10 format does not include the AS and RouterID for the router = certificate. Therefore, the operator must include the AS it has chosen = for the router and the RouterID when it sends the CSR to the RPKI CA.\ \pard\pardeftab720\partightenfactor0 \f1\fs22 \cf0 \ That should be a MUST, shouldn\'92t it? \f0\fs24 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \ p5, section 5.1\ \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 The operator adds the chosen AS number and the RouterID to send to\ the RPKI CA for the CA to certify.\ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \ My first reading was that the text meant the AS and RouterID were added = to the CSR. First, that\'92s not possible because of the signature, = unless there\'92s some key sharing going on. Second, that\'92s not = possible because the CSR format does not include the AS and RouterID. = Hence my comment above.\ \ suggest:\ \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 The operator includes the chosen AS number and the RouterID when it = sends the CSR to\ \ p4, section 5.1 (nit)\ \ NOTE: If a router was to communicate directly with a CA to have the\ \ suggest:\ \ NOTE: If a router were to communicate directly with a CA to have the\ \ p5, section 5.2\ \ and adds the chosen AS number and RouterID to be sent to the RPKI CA\ for the CA to certify.\ \ suggest:\ \ and includes the chosen AS number and the RouterID when it sends the = CSR to the RPKI CA\ for the CA to certify.\ \ p5, section 5.2.1\ \ section title \'93Using PKCS#8 to Transfer Public Key\'94\ \ \pard\pardeftab720\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 PKCS#8 in RFC5958 can transfer public = keys. But the following text is talking about transferring the private = key to the router. \ \ I think this title should be \expnd0\expndtw0\kerning0 \'93Using PKCS#8 to Transfer Private Key\'94\ \ \ A private key encapsulated in a PKCS #8 [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5958"}}{\fldrslt \cf3 \ul RFC5958}}] = should be further\ encapsulated in Cryptographic Message Syntax (CMS) SignedData\ [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5652"}}{\fldrslt \cf2 \ul \ulc2 = RFC5652}}] and signed with the AS's End Entity (EE) private key.\ \ \pard\pardeftab720\partightenfactor0 \f1\fs22 \cf0 Would \'93A private key encapsulated in a PKCS #8\'94 be = followed by "OTOH, a private key that is not encapsulated in a = PKCS#8\'94? :-) \f0\fs24 \ \ Suggest:\ \ A private key can be encapsulated in a PKCS #8 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5958"}}{\fldrslt \cf3 \ul RFC5958}}] and = should be further\ (or \'93is\'94 encapsulated or \'93should be\'94 encapsulated) \ \ Section 3 suggests various ways to \'93exchange PKI-related information = with routers\'94. Is this PKCS#8 just one more way, or is it the = recommended way? The intro to section 5 suggests that copy and paste = could also be used, but doesn\'92t say if that would be copy and paste = of the PKCS#8. If Section 5 is also talking about straight copy and = paste of the hex or the PEM block, then that\'92s another alternative.\ \ RFC5958 discusses several \'93CMS protecting content types\'94 to = protect the AsymmetricKeyPackage. I presume that the = encryption/enveloping content types are not needed because = confidentiality is being provided by the protected channel. But then = why use the CMS SignedData - would not the protected channel provide the = authentication and integrity needed? (But see potential reason below)\ \ \ [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5652"}}{\fldrslt \cf2 \ul \ulc2 = RFC5652}}] and signed with the AS's End Entity (EE) private key.\ \ Does it matter which AS\'92s EE cert the operator uses to sign the = PKCS#8? I presume that the AS must match an AS with which the router is = configured. Should the router check that? Does a router that is = configured with multiple ASs use this communication to tie the private = key to the appropriate AS & BGPsec session? \ \ If the answer is yes to both questions, should those actions be = mentioned here?\ \ (I admit to being a bit dizzy here, but maybe the mapping of private = key to AS happens in the receipt of the router certificate.) \ \ include in the SignedData the RPKI CA certificate and relevant AS's\ EE certificate(s). \ \ Maybe this is the reason for using the SignedData - to be able to = include the AS\'92s EE cert and give the router the means to tie the = private key to the right AS.\ \ The router SHOULD verify the signature of the encapsulated PKCS#8 to\ ensure the returned private key did in fact come from the operator,\ \ Then shouldn\'92t it be signed with the operator\'92s personal cert? = :-) \ \ include in the SignedData the RPKI CA certificate and relevant AS's\ EE certificate(s).\ \ Elsewhere (sections 6 & 7) it mentions including the entire cert chain. = Should that be mentioned here as well?\ \ p5, section 6 (nit)\ \ The operator uses RPKI management tools to communicate with the\ global RPKI system to have the appropriate CA validate the PKCS#10\ request, sign the key in the PKCS#10 (i.e., certify it) and = generated\ PKCS#7 response, as well as publishing the certificate in the Global\ RPKI.\ \ for symmetry, suggest:\ \ The operator uses RPKI management tools to communicate with the\ global RPKI system to have the appropriate CA validate the PKCS#10\ request, sign the key in the PKCS#10 (i.e., certify it) and generate = a\ PKCS#7 response, as well as publish the certificate in the Global\ RPKI.\kerning1\expnd0\expndtw0 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 p5, section 6 \kerning1\expnd0\expndtw0 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 External network connectivity may be needed if the = certificate\ is to be published in the Global RPKI.\ \ The previous sentence and the following paragraph do not hint that there = is any \'93if\'94 about the publication of the certificate. Is there a = case where the certificate is NOT \'93to be published in the Global = RPKI\'94?\ \ p6, section 6 (nit)\ \ 2. Returns the certificate to the operator's management station,\ packaged in a PKCS#7\ \ Needs a reference. RFC2315?\ \ In the operator-generated method, the operator SHOULD extract the\ certificate from the PKCS#7, and verify that the private key it = holds\ corresponds to the returned public key.\ \ \'93it\'94 means the operator, right?\ \ You get to Appendix B before the verification of the correspondence is = explained. I think it should be explained here.\ \ The Appendix B says the operator should verify the signature on the = PKCS#10 CSR to verify the correspondence. But the operator generated = the key - can\'92t the correspondence be verified by checking the = certificate\'92s public key against the operator generated public key = (presuming the key was retained)? That seems too easy - I fear I am = missing some important part here.\ \ p6, section 7\ \ The router SHOULD extract the certificate from the PKCS#7 and verify\ that the public key corresponds to the stored private key. \ \ I think more needs to be said about how the correspondence would be = verified. \ \ Appendix B says the operator should verify the signature on the PKCS#10 = with the certificate to verify the correspondence to the private key. = That would work for the router as well if the router generated the = PKCS#10, but not if the operator generated the key pair and the PKCS#10. = But the router could sign any random bunch of bits and verify the = signature with the certificate to verify the correspondence. Should = those things be said?\ \ Also, in the router-driven method, the router can verify the = correspondence simply by matching the certificate\'92s public key with = one of the router\'92s stored public keys. (Right? What am I missing = here?)\ \ Should the router also verify that the AS mentioned in the returned = router certificate is an AS with which it is configured?\ \ For a router that is configured with multiple ASs, is this where the = router ties the private key to the AS & BGPsec session with which the = private key should be used?\ \ The last two paragraphs of section 7 confuse me.\ \ Even if the operator cannot extract the private key from the router,\ this signature still provides a linkage between a private key and a\ router. That is the operator can verify the proof of possession\ (POP), as required by [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6484"}}{\fldrslt \cf2 \ul \ulc2 = RFC6484}}].\ \ What is \'93this signature\'94? And there\'92s been no mention in this = section of extracting the private key from the router.\ \ This sounds to me like it belongs in section 5.1, maybe after: \ \'93to = sign\ the PKCS#10 with the private key. Once generated, the PKCS#10 is\ returned to the operator over the protected channel.\ \ And then:\ \ NOTE: The signature on the PKCS#8 and Certificate need not be made = by\ the same entity. Signing the PKCS#8, permits more advanced\ configurations where the entity that generates the keys is not the\ direct CA.\ \ Maybe this belongs in section 5.2.1 where it is talking about the = PKCS#8?\ \ Even so, I\'92m not sure what Certificate this text references. The AS = EE cert?\ \ Both the router-driven method and the operator-driven method are not the = direct CA. Nowhere in this draft does it mention the CA generating the = keys. So the entire draft is one of these \'93advanced = configurations\'94. What am I missing here?\ \ p7, section 8 (nit)\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 Transport" [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc7030"}}{\fldrslt \cf3 \ul RFC7030}}] or = the original CMC transport protocol's\ \ Is the possessive really needed here? I didn\'92t peruse the RFC5273 = thoroughly, but I can see that it defines a number of transport methods, = so maybe there is a \'93CMC transport protocol\'92s X\'94 missing here.\ \ \pard\pardeftab720\partightenfactor0 \fs24 \cf0 p7, section 8\ \ \ This section uses \'93key material\'94 several places. But I\'92m not = certain each use is talking about the same key material.\ \ When the operator first establishes a secure\ communication channel between the management system and the router,\ this pre-installed key material is used to authenticate the router.\ \ So the router gets keys as part of the manufacturing, where the = \'93pre-installed key material\'94 can be used in communication with the = operator.\ \ I can see that this might make it easier for the router to communicate = directly with the CA and authenticate itself using these keys. But = section 5.1 notes that the CA has no way to authenticate the router. I = don\'92t know that the pre-installed key material could provide that way = to authenticate the router, without the participation of the operator at = some point.\ \ The operator burden shifts here to include:\ \ I\'92m not sure how to read this. Maybe \'93The operator burdens that = shift here can/will include\'94.\ \ I\'92m also not sure if both 1 and 2 are presumed to be shifted/lifted, = or if it is either.\ \ \ 1. Securely communicating the router's authentication material to\ the CA prior to operator initiating the router's CSR. CAs use\ authentication material to determine whether the router is\ eligible to receive a certificate. Authentication material at a\ minimum includes the router's AS number and RouterID as well as\ the router's key material, but can also include additional\ information. Authentication material can be communicated to the\ CA (i.e., CSRs signed by this key material are issued\ certificates with this AS and RouterID) or to the router (i.e.,\ the operator uses the vendor-supplied management interface to\ include the AS number and routerID in the router-generated CSR).\ \ Who is doing=20 \f1\fs22 the communicating in=20 \f0\fs24 \'93securely communicating to the CA\'94 and \'93can be = communicated to the CA\'94? In the following paragraph, the text says = \'93the router is communicating directly with the CA\'94 - is the = communication in this part 1 text going from the router to the CA?\ \ What is the \'93router\'92s key material\'94? I could read it both = ways:\ \ The paragraph above says that the pre-installed key material is used to = authenticate the router, so maybe the \'93router\'92s key material\'94 = is the pre-installed key material. The text says that the CA = \'93uses\'94 the authentication material, which includes the router\'92s = key material, to determine whether to issue the certificate. I don\'92t = know how the pre-installed key material could assure the CA that the = router could be issued a cert, without some coordination with the = operator about that particular key material.\ \ Then the text says \'93CSRs signed by this key material\'94 which = implies that the \'93router\'92s key material\'94 is the public/private = key pair.\ \ So I\'92m not certain what is going on here, or how the pre-installed = key material is helping.\ \ \ Once configured, the operator can begin the process of enrolling the\ router. \ \ What does \'93once configured\'94 mean? configuring the router-operator = protected channel? Doing the communication of authentication material = in 1 and 2 above? Configuring the router with AS and RouterID?\ \ Because the router is communicating directly with the CA,\ there is no need for the operator to retrieve the PKCS#10 from the\ router or return the PKCS#7 to the router as in \cf2 \ul \ulc2 = Section 6\cf0 \ulnone . Note that\ the checks performed by the router,\ \ Section 5 says the router returns the PKCS#10 to the operator.\ Section 7 says the operator sends the PKCS#7 to the router and the = router performs checks.\ \ suggest:\ \ Because the router is communicating directly with the CA,\ there is no need for the operator to retrieve the PKCS#10 from the\ router as in Section 5 or return the PKCS#7 to the router as in \cf2 = \ul Section 7\cf0 \ulnone . Note that\ the checks performed by the router in Section 7,\ \ When a router is so configured the communication with the CA SHOULD\ be automatically re-established\ \ what does \'93so configured\'94 mean here? configured with = pre-installed key material? configured by the operator with AS and = RouterID?\ \ p8, section 9.1 (nit)\ \ just for symmetry:\ \ 4. Use some other kind of automated process to search for and track\ \ suggest:\ \ 4. The operator uses some other kind of automated process to search = for and track\ \ p8, section 9.1\ \ Regardless of the technique used to track router certificate expiry\ times, it is advisable to notify additional operators in the same\ organization\ \ \'93notify additional operators\'94 \'97 In addition to what? or after = what?\ \ I think you mean \'93multiple\'94 operators, or I misunderstand.\ \ p9, section 9.3 (nits)\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 certificate to the router), and distributing the status = takes time\ \ Not sure what you mean by \'93status\'94 that needs to be distributed. = Are you talking about distributing the revocation \'93status\'94 in the = CRL?\ \ Keeping the router operational and BGPsec-speaking is the ideal = goal,\ but if operational practices do not allow this then reconfiguring = the\ router to disabling BGPsec is likely preferred to bringing the = router\ offline.\ \ suggest:\ \ router to disable BGPsec is likely preferred to bringing the router\ \ p10, section 9.4\ \ To allow operators to quickly replace routers without requiring\ update and distribution of the corresponding public keys in the = RPKI,\ routers SHOULD allow the private BGPsec key to inserted via a\ protected session, e.g., SSH, NetConf (see = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6470"}}{\fldrslt \cf2 \ul RFC6470}}]), = SNMP. This\ lets the operator escrow the old private key via the mechanism used\ for operator-generated keys, see \cf2 \ul Section 5.2\cf0 \ulnone , = such that it can be re-\ inserted into a replacement router.\ \ The topic here is routers that won\'92t allow off-loading of their keys. = \ \ \'93routers SHOULD allow the private BGPsec key to inserted\'94\ \ is the router that is doing the allowing the old, soon to be replaced = routers, or the newly installed routers?\ \ \'93to inserted\'94 - where? - in the newly installed router or in = the management station?\ \ \'93This lets the operator escrow the old private key\'94 - sounds like = the old router is allowing the private key to be \'93inserted in\'94 = (exported to?) the management station. Right?\ \ Is there a suggestion of how to get the routers to allow export of the = key \f1\fs22 , which is currently not allowed \f0\fs26 ?\ \ I don\'92t see that section 5.2 says anything about a mechanism for = escrowing keys. It talks about installing a private key into a router = over the protected channel. If the citation to 5.2 is about the = \'93such that it can be re-inserted\'94 part of the sentence, then I get = it. But the citation should move to the end of the sentence.\ \ p10, section 10 (nit)\ \ After\ familiarizing one's self with the capabilities of the router,\ operators are encouraged\ \pard\pardeftab720\partightenfactor0 \fs24 \cf0 \ suggest:\ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 \ After\ familiarizing themselves with the capabilities of the router,\ operators are encouraged\ \ \ or\ \ After\ familiarizing one's self with the capabilities of the router,\ an operator is encouraged\ \ p11, section 10 (nit)\ \ employees that no longer need access to\ routers SHOULD be removed the router \ \ suggest\ \ employees that no longer need access to\ a router SHOULD be removed from the router \ \ or\ \ employees that no longer need access to\ a router SHOULD be removed from the router access [list]\ \ p11, section 10 (nit)\ \ The\ operator MUST ensure that installed CA certificate is valid.\ \ suggest:\ \ The\ operator MUST ensure that the installed CA certificate is valid.\ \ p14, section Appendix A\ \ x509v3-ecdsa-sha2-nistp256 [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6187"}}{\fldrslt \cf2 \ul RFC6187}}] = could be used for\ authentication.\ \ is that an example, or a recommendation?\ \ p15, section Appendix B (nit)\ \ that will generate the key pair for the algorithms noted in the main\ body of this document;\ \ the algorithms are not noted in the main body, but the end of section 1 = does cite RFC8208. \ \ the private key just generated to sign the certification request = with\ the algorithms specified in the main body of this document;\ \ the algorithms are not specified in the main body, but the end of = section 1 does cite RFC8208.\ \ p16, Appendix B\ \ Uses of \'93serial number\'94:\ \ the subject name and serial number for the router. The CA needs = this\ and\ CSR you sent; the certificate will include the subject name, serial\ number, public key, and other fields\ and\ Create CSR and sign CSR with private key, and; o Step 3: Send CSR\ file with the subject name and serial number to CA.\ \ The first of these seem to mean the BGP Identifier aka RouterID. As = said before, RFC4271 and RFC8209 use the term BGP Identifier.\ \ The second and third use of \'93serial number\'94 probably also mean BGP = Identifier aka RouterID (not the issued cert\'92s serial number).\ \ p17, section Appendix B (typo nit)\ \ way through GPsec-enabling the router.\ \ suggest:\ \ way through BGPsec-enabling the router.\ \ p17, section Appendix B\ \ To avoid having routers with expired certificates\ follow the recommendations in the Certification Policy (CP) = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6484"}}{\fldrslt \cf2 \ul RFC6484}}]\ \ you could also mention section 9.1.\ }= --Apple-Mail=_B650AB11-8314-4AEC-8E6B-78E1EF5C4751 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 20, 2017, at 1:04 PM, Sean Turner wrote: >=20 > Chris, >=20 > This version includes changes to address Oliver=E2=80=99s and = Sriram=E2=80=99s comments. >=20 > spt >=20 >> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote: >>=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 WG of = the IETF. >>=20 >> Title : Router Keying for BGPsec >> Authors : Randy Bush >> Sean Turner >> Keyur Patel >> Filename : draft-ietf-sidr-rtr-keying-14.txt >> Pages : 17 >> Date : 2017-10-20 >>=20 >> Abstract: >> BGPsec-speaking routers are provisioned with private keys in order = to >> sign BGPsec announcements. The corresponding public keys are >> published in the global Resource Public Key Infrastructure, enabling >> verification of BGPsec messages. This document describes two = methods >> of generating the public-private key-pairs: router-driven and >> operator-driven. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-14 >>=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 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_B650AB11-8314-4AEC-8E6B-78E1EF5C4751-- From nobody Tue Nov 14 07:33:15 2017 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 8239412700F; Tue, 14 Nov 2017 07:33:14 -0800 (PST) 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, 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 19CPA_vT2AFU; Tue, 14 Nov 2017 07:33:12 -0800 (PST) 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 A9FFC126C89; Tue, 14 Nov 2017 07:33:12 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0DF4228B0041; Tue, 14 Nov 2017 10:33:12 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 01D231F8036; Tue, 14 Nov 2017 10:33:12 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> Date: Tue, 14 Nov 2017 10:33:11 -0500 Cc: Sandra Murphy , Christopher Morrow , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org, sidr list Content-Transfer-Encoding: quoted-printable Message-Id: <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:33:14 -0000 Speaking as wg co-chair Please, wg, do take a look at the comments attached. This draft was = requested by the operators and is important. Some of the comments are about substance. Those at the very least must = be considered by the wg. Please take advantage of focused attention and close proximity at the = IETF meeting to discuss. =20 I unfortunately can not be there to button hole people and shove = printouts into their hands. =E2=80=94Sandy, speaking as wg co-chair > On Nov 5, 2017, at 9:25 PM, Sandra Murphy wrote: >=20 > I=E2=80=99m attaching some comments and questions I found in the -14 = version. >=20 > =E2=80=94Sandy >=20 > >=20 >> On Oct 20, 2017, at 1:04 PM, Sean Turner wrote: >>=20 >> Chris, >>=20 >> This version includes changes to address Oliver=E2=80=99s and = Sriram=E2=80=99s comments. >>=20 >> spt >>=20 >>> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote: >>>=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 WG of = the IETF. >>>=20 >>> Title : Router Keying for BGPsec >>> Authors : Randy Bush >>> Sean Turner >>> Keyur Patel >>> Filename : draft-ietf-sidr-rtr-keying-14.txt >>> Pages : 17 >>> Date : 2017-10-20 >>>=20 >>> Abstract: >>> BGPsec-speaking routers are provisioned with private keys in order = to >>> sign BGPsec announcements. The corresponding public keys are >>> published in the global Resource Public Key Infrastructure, enabling >>> verification of BGPsec messages. This document describes two = methods >>> of generating the public-private key-pairs: router-driven and >>> operator-driven. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >>> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-14 >>>=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 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Tue Nov 14 07:36:38 2017 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 94F5C128B44; Tue, 14 Nov 2017 07:36:35 -0800 (PST) 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, 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 SiNRMMkiNCLi; Tue, 14 Nov 2017 07:36:32 -0800 (PST) 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 F381E128961; Tue, 14 Nov 2017 07:36:31 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 641B228B0041; Tue, 14 Nov 2017 10:36:31 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1A3511F8036; Tue, 14 Nov 2017 10:36:31 -0500 (EST) Content-Type: multipart/mixed; boundary="Apple-Mail=_AC30B402-86BE-46EF-89E0-0204650424D8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> Date: Tue, 14 Nov 2017 10:36:30 -0500 Cc: Sandra Murphy , Christopher Morrow , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org, sidr list Message-Id: <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:36:36 -0000 --Apple-Mail=_AC30B402-86BE-46EF-89E0-0204650424D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry, the reply did not pick up the original attachment. Attached here. Let me know if there are problems reading the comments. =E2=80=94Sandy --Apple-Mail=_AC30B402-86BE-46EF-89E0-0204650424D8 Content-Disposition: attachment; filename=draft-ietf-sidr-rtr-keying-14.mycomments.rtf Content-Type: text/rtf; name="draft-ietf-sidr-rtr-keying-14.mycomments.rtf" Content-Transfer-Encoding: quoted-printable {\rtf1\ansi\ansicpg1252\cocoartf1404\cocoasubrtf470 {\fonttbl\f0\fmodern\fcharset0 Courier;\f1\fnil\fcharset0 = Menlo-Regular;} = {\colortbl;\red255\green255\blue255;\red0\green0\blue233;\red66\green1\blu= e120;} \margl1440\margr1440\vieww16220\viewh17060\viewkind0 = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \f0\fs24 \cf0 Points that might get lost in the long detailed list that = follows:\ \ 1. RFC4271 (and RFC6286) and RFC8209 use the term \'93BGP = Identifier\'94. The main text says RouterID and the Appendix B says = \'93serial number\'94. I believe both are talking about what RFC8209 = calls the \'93BGP Identifier\'94. Most of the tech sites say router ID = or router-id or routerid or RID or some such. But I think consistency = with the referenced text would be good.\ \ 2. I was initially confused by the text in various places that talks = about the operator adding the AS and RouterID (sic) and sends to the CA. = I thought that meant the operator adds those to the CSR, which would be = hard since the CSR is signed. This occurs a couple of places. I = suggest a sentence early on that says the router certificate includes = the AS and router identifier but the CSR does not include such fields, = so the operator must include the AS and routerID when it sends the CSR = to the CA.\ \ 3. \'93corresponds\'94 - there are several places that say the = certificate must be validated to prove that the public key corresponds = with the private key. The main body does not say how that = correspondence is validated. The appendix suggests that the operator = could validate the signature on the CSR with the returned router cert in = order to validate the key. (a) When the operator generated the = public/private key pair, why not just do a comparison to the generated = public key, presuming it was retained? (b) When the operator passed the = CSR generated by the router to the CA, why not validate the public key = before sending it to the CA? The public key in the returned router = certificate could subsequently be validated by a comparison, presuming = the public key was retained. (c) When the router is supposed to = validate the public key of the router cert it receives, and the operator = generated the public/private key pair, it does not have a copy of the = CSR to validate the correspondence. Took me a bit to realize the router = could sign just any old bit of bytes and then validate the signature = with the received router cert. Right?\ \ 4. \'93corresponds\'94 again - there\'92s no mention of a router = verifying that the router cert it receives has an AS that is configured = on the router. There are lots of other checks and double checks - why = not this one? And if the router has multiple ASs and multiple CSRs have = been generated (either by the router or by the operator), then the = router uses the received router certificate to associate the AS with the = public/private key pair, so it knows which private key to use over which = session. Right?\ \ 5. Section 8 on \'93\expnd0\expndtw0\kerning0 Advanced Deployment Scenarios\'94\kerning1\expnd0\expndtw0 talks about = routers that already have pre-installed keys (with mentions of types of = crypto that are not known to me, and I did not dig up the refs, so I = might be missing something here). The first paragraph talks about = \'93pre-installed key material\'94. I could understand why these = pre-installed keys might be useful in authenticating the router directly = to the CA. The \'93burdens\'94 1 and 2 also talk abut \'93key = material\'94. It did not look to me like the \'93key material\'94 in 1 = and 2 are talking about these \'93pre-installed\'94 keys. But I admit = to being very confused by the way the term is used.\ \ 6. Section 5.2.1 is titled \'94\expnd0\expndtw0\kerning0 Using PKCS#8 to Transfer Public Key\kerning1\expnd0\expndtw0 \'94. The = text talks about using PKCS #8 in RFC5958, which allows for including = both the public and private key. But the text of that section is = talking about using PKCS #8 to transmit the private key to the router. = I presume the title should be \expnd0\expndtw0\kerning0 Using PKCS#8 to Transfer Private Key\kerning1\expnd0\expndtw0 \ \ 7. There is an early assumption that all the communication between the = operator and the router is over a protected channel. Section 5.2.1 = suggests using a CMS SignedData to transmit the PKCS#8. RFC5958 = suggests several different \'93CMS protecting content types\'94 for the = PKCS#8 - EncryptedData, EnvelopedData, etc. I presume that the = encrypted versions are not used here because the protected channel = ensures confidentiality. So (a) Appendix A talks about the key strength = to be used for the different crypto algorithms (encryption, key = exchange, \'85). That\'92s a big hint that the channel should provide = the related security protections. I think it would be good to = explicitly state the protections the protected channel must provide: = \'93The protected channel must provide confidentiality, authentication, = integrity and replay protection\'94. (b) if the protected channel = provides authentication and integrity, why is the protection of the CMS = SignedData needed? One possible reason follows -> (c) The AS EE = certificate has an AS extension, not an IP extension, I presume. So the = AS EE certificate would be a second way for the router to associate a = private key with an AS and an appropriate BGP session (see my comment 3c = above). But this applies only when the operator generated the = public/private key pair.\ \ 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines = several types of content, e.g., signed-data, \expnd0\expndtw0\kerning0 enveloped-data, signed-and-enveloped-data, etc. Is there any reason to = specify which type? Is it operator choice?\ \ 9. The term \'93operator\'94 is used to talk about carbon-based units = (who are forgetful), ISP organizations (who peer with other operators), = ASs (who have an AS EE certificates) and management system stations = (that receive CSRs from the router). It was a bit unsettling, but after = multiple reads through I\'92m getting used to it. I\'92m not sure I = could suggest a term that would fit all those uses. Perhaps network = operators (the ones with DNA) identify personally with all those uses = and think of their person in all cases. \'93I am the AS\'94, \'93I am = the peering entity\'94, \'93I am the management of the network\'94, = etc.\ \ 10. I do not understand the last two paragraphs of section 7 at the = bottom of page 6. It sounds to me like they are out of place, like they = belong elsewhere in the text.\ \ 11. There are some occurrences of \'93must\'94 and only a few of = \'93MUST\'94 - the draft is standards track, so how much of the = described behaviors are mandatory?\ \ 12. Some consistency nits - PKCS sometimes followed by a space, = sometimes not. protected channel, secure channel, communications = channel, protected session, SSH session, . . . \ \ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ \ OK, so on to the detailed comments, sequentially through the document\ \ p3, section 1:\ \ \pard\pardeftab720\partightenfactor0 \cf0 two methods to provision new and existing routers. The methods\ described involve the operator configuring the two end points and\ acting as the intermediary.\ \ What are the two endpoints? The router and the management station? The = router and the CA? I can imagine the operator configuring the = management station, but not the CA. I can imagine the operator acting = as the intermediary between the router and the CA, but not between the = router and the management station.\ \ p3, section 1: (nit)\ \ \fs26 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc8208"}}{\fldrslt \cf2 \ul \ulc2 = RFC8208}}] \fs24 \ \fs26 specifies the algorithms used to generate the signature.\ \fs24 \ If I read correctly, \'93the\'94 signature in this text would be the = signature on the PKCS#10. \ \ suggest:\ \ \fs26 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc8208"}}{\fldrslt \cf2 \ul \ulc2 = RFC8208}}] \fs24 \ \fs26 specifies the algorithms used to generate the PKCS#10 = signature. \fs24 \ \ \ p4, section 2\ \ See \cf3 \ul \ulc3 Appendix A\cf0 \ulnone = for security considerations\ for this channel.\ \ I think it is important to say what security protection are required for = this protected channel.\ Appendix A talks about the strength of the key used in the various = crypto algorithms. I think a\ sentence something like the following would be useful here or in = Appendix A.\ \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \'93The protected channel must provide = confidentiality, authentication, integrity\'94 and replay = protection.\'94\expnd0\expndtw0\kerning0 \ \pard\pardeftab720\partightenfactor0 \cf0 \ p4, section 4 (nit)\ \ appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router.\ \ suggest:\ \ appropriate RPKI Trust Anchor Certificate (TA Cert) in the router.\ or\ appropriate RPKI Trust Anchor\'92s Certificate (TA Cert) in the = router.\ \ p4, section 4\ \ The operator also configures the Autonomous System (AS) number to be\ used in the generated router certificate. This may be the sole AS\ configured on the router, or an operator choice if the router is\ configured with multiple ASs.\ \ There\'92s a hint here that the operator configures the router to = generate just one router certificate.\ RFC8209 allows the router certificate to have one or more ASs, but = recommends that there be multiple router certificates with one AS each. = Does this paragraph intend to limit a router to one router certificate = or just to limit the router to one AS per router certificate? I have = questions later about what happens if the router wants a router = certificate for each of multiple ASs.\ \ Perhaps \'93A router with multiple ASs can be configured with multiple = router certificates\'94, maybe also \'93by following the process of this = document for reach desired certificate\'94.\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 The operator configures or extracts from the router the = BGP RouterID\ \ RFC4271 and RFC8209 say \'93BGP Identifier\'94. OSPF uses RouterID, and = lots of C/J commands use RouterID, or router-id, or router id, or RID, = or . . . But consistency with the referenced specs would a good thing. \fs24 \ \ p4, section 5\ \ I think it would be great to add a sentence here explaining that the = PKCS#10 (CSR) format does not include the AS and RouterID (sic). = Therefore, the operator must transmit the AS and RouterID (sic) as well = when it sends the CSR to the CA. \ \ That sentence applies to both the router generated keys and the operator = generated keys, so maybe it could go here.\ \ The PKCS#10 format does not include the AS and RouterID for the router = certificate. Therefore, the operator must include the AS it has chosen = for the router and the RouterID when it sends the CSR to the RPKI CA.\ \pard\pardeftab720\partightenfactor0 \f1\fs22 \cf0 \ That should be a MUST, shouldn\'92t it? \f0\fs24 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \ p5, section 5.1\ \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 The operator adds the chosen AS number and the RouterID to send to\ the RPKI CA for the CA to certify.\ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 \ My first reading was that the text meant the AS and RouterID were added = to the CSR. First, that\'92s not possible because of the signature, = unless there\'92s some key sharing going on. Second, that\'92s not = possible because the CSR format does not include the AS and RouterID. = Hence my comment above.\ \ suggest:\ \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 The operator includes the chosen AS number and the RouterID when it = sends the CSR to\ \ p4, section 5.1 (nit)\ \ NOTE: If a router was to communicate directly with a CA to have the\ \ suggest:\ \ NOTE: If a router were to communicate directly with a CA to have the\ \ p5, section 5.2\ \ and adds the chosen AS number and RouterID to be sent to the RPKI CA\ for the CA to certify.\ \ suggest:\ \ and includes the chosen AS number and the RouterID when it sends the = CSR to the RPKI CA\ for the CA to certify.\ \ p5, section 5.2.1\ \ section title \'93Using PKCS#8 to Transfer Public Key\'94\ \ \pard\pardeftab720\partightenfactor0 \cf0 \kerning1\expnd0\expndtw0 PKCS#8 in RFC5958 can transfer public = keys. But the following text is talking about transferring the private = key to the router. \ \ I think this title should be \expnd0\expndtw0\kerning0 \'93Using PKCS#8 to Transfer Private Key\'94\ \ \ A private key encapsulated in a PKCS #8 [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5958"}}{\fldrslt \cf3 \ul RFC5958}}] = should be further\ encapsulated in Cryptographic Message Syntax (CMS) SignedData\ [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5652"}}{\fldrslt \cf2 \ul \ulc2 = RFC5652}}] and signed with the AS's End Entity (EE) private key.\ \ \pard\pardeftab720\partightenfactor0 \f1\fs22 \cf0 Would \'93A private key encapsulated in a PKCS #8\'94 be = followed by "OTOH, a private key that is not encapsulated in a = PKCS#8\'94? :-) \f0\fs24 \ \ Suggest:\ \ A private key can be encapsulated in a PKCS #8 = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5958"}}{\fldrslt \cf3 \ul RFC5958}}] and = should be further\ (or \'93is\'94 encapsulated or \'93should be\'94 encapsulated) \ \ Section 3 suggests various ways to \'93exchange PKI-related information = with routers\'94. Is this PKCS#8 just one more way, or is it the = recommended way? The intro to section 5 suggests that copy and paste = could also be used, but doesn\'92t say if that would be copy and paste = of the PKCS#8. If Section 5 is also talking about straight copy and = paste of the hex or the PEM block, then that\'92s another alternative.\ \ RFC5958 discusses several \'93CMS protecting content types\'94 to = protect the AsymmetricKeyPackage. I presume that the = encryption/enveloping content types are not needed because = confidentiality is being provided by the protected channel. But then = why use the CMS SignedData - would not the protected channel provide the = authentication and integrity needed? (But see potential reason below)\ \ \ [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc5652"}}{\fldrslt \cf2 \ul \ulc2 = RFC5652}}] and signed with the AS's End Entity (EE) private key.\ \ Does it matter which AS\'92s EE cert the operator uses to sign the = PKCS#8? I presume that the AS must match an AS with which the router is = configured. Should the router check that? Does a router that is = configured with multiple ASs use this communication to tie the private = key to the appropriate AS & BGPsec session? \ \ If the answer is yes to both questions, should those actions be = mentioned here?\ \ (I admit to being a bit dizzy here, but maybe the mapping of private = key to AS happens in the receipt of the router certificate.) \ \ include in the SignedData the RPKI CA certificate and relevant AS's\ EE certificate(s). \ \ Maybe this is the reason for using the SignedData - to be able to = include the AS\'92s EE cert and give the router the means to tie the = private key to the right AS.\ \ The router SHOULD verify the signature of the encapsulated PKCS#8 to\ ensure the returned private key did in fact come from the operator,\ \ Then shouldn\'92t it be signed with the operator\'92s personal cert? = :-) \ \ include in the SignedData the RPKI CA certificate and relevant AS's\ EE certificate(s).\ \ Elsewhere (sections 6 & 7) it mentions including the entire cert chain. = Should that be mentioned here as well?\ \ p5, section 6 (nit)\ \ The operator uses RPKI management tools to communicate with the\ global RPKI system to have the appropriate CA validate the PKCS#10\ request, sign the key in the PKCS#10 (i.e., certify it) and = generated\ PKCS#7 response, as well as publishing the certificate in the Global\ RPKI.\ \ for symmetry, suggest:\ \ The operator uses RPKI management tools to communicate with the\ global RPKI system to have the appropriate CA validate the PKCS#10\ request, sign the key in the PKCS#10 (i.e., certify it) and generate = a\ PKCS#7 response, as well as publish the certificate in the Global\ RPKI.\kerning1\expnd0\expndtw0 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 p5, section 6 \kerning1\expnd0\expndtw0 \ = \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200= \tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \pard\pardeftab720\partightenfactor0 \cf0 \expnd0\expndtw0\kerning0 External network connectivity may be needed if the = certificate\ is to be published in the Global RPKI.\ \ The previous sentence and the following paragraph do not hint that there = is any \'93if\'94 about the publication of the certificate. Is there a = case where the certificate is NOT \'93to be published in the Global = RPKI\'94?\ \ p6, section 6 (nit)\ \ 2. Returns the certificate to the operator's management station,\ packaged in a PKCS#7\ \ Needs a reference. RFC2315?\ \ In the operator-generated method, the operator SHOULD extract the\ certificate from the PKCS#7, and verify that the private key it = holds\ corresponds to the returned public key.\ \ \'93it\'94 means the operator, right?\ \ You get to Appendix B before the verification of the correspondence is = explained. I think it should be explained here.\ \ The Appendix B says the operator should verify the signature on the = PKCS#10 CSR to verify the correspondence. But the operator generated = the key - can\'92t the correspondence be verified by checking the = certificate\'92s public key against the operator generated public key = (presuming the key was retained)? That seems too easy - I fear I am = missing some important part here.\ \ p6, section 7\ \ The router SHOULD extract the certificate from the PKCS#7 and verify\ that the public key corresponds to the stored private key. \ \ I think more needs to be said about how the correspondence would be = verified. \ \ Appendix B says the operator should verify the signature on the PKCS#10 = with the certificate to verify the correspondence to the private key. = That would work for the router as well if the router generated the = PKCS#10, but not if the operator generated the key pair and the PKCS#10. = But the router could sign any random bunch of bits and verify the = signature with the certificate to verify the correspondence. Should = those things be said?\ \ Also, in the router-driven method, the router can verify the = correspondence simply by matching the certificate\'92s public key with = one of the router\'92s stored public keys. (Right? What am I missing = here?)\ \ Should the router also verify that the AS mentioned in the returned = router certificate is an AS with which it is configured?\ \ For a router that is configured with multiple ASs, is this where the = router ties the private key to the AS & BGPsec session with which the = private key should be used?\ \ The last two paragraphs of section 7 confuse me.\ \ Even if the operator cannot extract the private key from the router,\ this signature still provides a linkage between a private key and a\ router. That is the operator can verify the proof of possession\ (POP), as required by [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6484"}}{\fldrslt \cf2 \ul \ulc2 = RFC6484}}].\ \ What is \'93this signature\'94? And there\'92s been no mention in this = section of extracting the private key from the router.\ \ This sounds to me like it belongs in section 5.1, maybe after: \ \'93to = sign\ the PKCS#10 with the private key. Once generated, the PKCS#10 is\ returned to the operator over the protected channel.\ \ And then:\ \ NOTE: The signature on the PKCS#8 and Certificate need not be made = by\ the same entity. Signing the PKCS#8, permits more advanced\ configurations where the entity that generates the keys is not the\ direct CA.\ \ Maybe this belongs in section 5.2.1 where it is talking about the = PKCS#8?\ \ Even so, I\'92m not sure what Certificate this text references. The AS = EE cert?\ \ Both the router-driven method and the operator-driven method are not the = direct CA. Nowhere in this draft does it mention the CA generating the = keys. So the entire draft is one of these \'93advanced = configurations\'94. What am I missing here?\ \ p7, section 8 (nit)\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 Transport" [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc7030"}}{\fldrslt \cf3 \ul RFC7030}}] or = the original CMC transport protocol's\ \ Is the possessive really needed here? I didn\'92t peruse the RFC5273 = thoroughly, but I can see that it defines a number of transport methods, = so maybe there is a \'93CMC transport protocol\'92s X\'94 missing here.\ \ \pard\pardeftab720\partightenfactor0 \fs24 \cf0 p7, section 8\ \ \ This section uses \'93key material\'94 several places. But I\'92m not = certain each use is talking about the same key material.\ \ When the operator first establishes a secure\ communication channel between the management system and the router,\ this pre-installed key material is used to authenticate the router.\ \ So the router gets keys as part of the manufacturing, where the = \'93pre-installed key material\'94 can be used in communication with the = operator.\ \ I can see that this might make it easier for the router to communicate = directly with the CA and authenticate itself using these keys. But = section 5.1 notes that the CA has no way to authenticate the router. I = don\'92t know that the pre-installed key material could provide that way = to authenticate the router, without the participation of the operator at = some point.\ \ The operator burden shifts here to include:\ \ I\'92m not sure how to read this. Maybe \'93The operator burdens that = shift here can/will include\'94.\ \ I\'92m also not sure if both 1 and 2 are presumed to be shifted/lifted, = or if it is either.\ \ \ 1. Securely communicating the router's authentication material to\ the CA prior to operator initiating the router's CSR. CAs use\ authentication material to determine whether the router is\ eligible to receive a certificate. Authentication material at a\ minimum includes the router's AS number and RouterID as well as\ the router's key material, but can also include additional\ information. Authentication material can be communicated to the\ CA (i.e., CSRs signed by this key material are issued\ certificates with this AS and RouterID) or to the router (i.e.,\ the operator uses the vendor-supplied management interface to\ include the AS number and routerID in the router-generated CSR).\ \ Who is doing=20 \f1\fs22 the communicating in=20 \f0\fs24 \'93securely communicating to the CA\'94 and \'93can be = communicated to the CA\'94? In the following paragraph, the text says = \'93the router is communicating directly with the CA\'94 - is the = communication in this part 1 text going from the router to the CA?\ \ What is the \'93router\'92s key material\'94? I could read it both = ways:\ \ The paragraph above says that the pre-installed key material is used to = authenticate the router, so maybe the \'93router\'92s key material\'94 = is the pre-installed key material. The text says that the CA = \'93uses\'94 the authentication material, which includes the router\'92s = key material, to determine whether to issue the certificate. I don\'92t = know how the pre-installed key material could assure the CA that the = router could be issued a cert, without some coordination with the = operator about that particular key material.\ \ Then the text says \'93CSRs signed by this key material\'94 which = implies that the \'93router\'92s key material\'94 is the public/private = key pair.\ \ So I\'92m not certain what is going on here, or how the pre-installed = key material is helping.\ \ \ Once configured, the operator can begin the process of enrolling the\ router. \ \ What does \'93once configured\'94 mean? configuring the router-operator = protected channel? Doing the communication of authentication material = in 1 and 2 above? Configuring the router with AS and RouterID?\ \ Because the router is communicating directly with the CA,\ there is no need for the operator to retrieve the PKCS#10 from the\ router or return the PKCS#7 to the router as in \cf2 \ul \ulc2 = Section 6\cf0 \ulnone . Note that\ the checks performed by the router,\ \ Section 5 says the router returns the PKCS#10 to the operator.\ Section 7 says the operator sends the PKCS#7 to the router and the = router performs checks.\ \ suggest:\ \ Because the router is communicating directly with the CA,\ there is no need for the operator to retrieve the PKCS#10 from the\ router as in Section 5 or return the PKCS#7 to the router as in \cf2 = \ul Section 7\cf0 \ulnone . Note that\ the checks performed by the router in Section 7,\ \ When a router is so configured the communication with the CA SHOULD\ be automatically re-established\ \ what does \'93so configured\'94 mean here? configured with = pre-installed key material? configured by the operator with AS and = RouterID?\ \ p8, section 9.1 (nit)\ \ just for symmetry:\ \ 4. Use some other kind of automated process to search for and track\ \ suggest:\ \ 4. The operator uses some other kind of automated process to search = for and track\ \ p8, section 9.1\ \ Regardless of the technique used to track router certificate expiry\ times, it is advisable to notify additional operators in the same\ organization\ \ \'93notify additional operators\'94 \'97 In addition to what? or after = what?\ \ I think you mean \'93multiple\'94 operators, or I misunderstand.\ \ p9, section 9.3 (nits)\ \ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 certificate to the router), and distributing the status = takes time\ \ Not sure what you mean by \'93status\'94 that needs to be distributed. = Are you talking about distributing the revocation \'93status\'94 in the = CRL?\ \ Keeping the router operational and BGPsec-speaking is the ideal = goal,\ but if operational practices do not allow this then reconfiguring = the\ router to disabling BGPsec is likely preferred to bringing the = router\ offline.\ \ suggest:\ \ router to disable BGPsec is likely preferred to bringing the router\ \ p10, section 9.4\ \ To allow operators to quickly replace routers without requiring\ update and distribution of the corresponding public keys in the = RPKI,\ routers SHOULD allow the private BGPsec key to inserted via a\ protected session, e.g., SSH, NetConf (see = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6470"}}{\fldrslt \cf2 \ul RFC6470}}]), = SNMP. This\ lets the operator escrow the old private key via the mechanism used\ for operator-generated keys, see \cf2 \ul Section 5.2\cf0 \ulnone , = such that it can be re-\ inserted into a replacement router.\ \ The topic here is routers that won\'92t allow off-loading of their keys. = \ \ \'93routers SHOULD allow the private BGPsec key to inserted\'94\ \ is the router that is doing the allowing the old, soon to be replaced = routers, or the newly installed routers?\ \ \'93to inserted\'94 - where? - in the newly installed router or in = the management station?\ \ \'93This lets the operator escrow the old private key\'94 - sounds like = the old router is allowing the private key to be \'93inserted in\'94 = (exported to?) the management station. Right?\ \ Is there a suggestion of how to get the routers to allow export of the = key \f1\fs22 , which is currently not allowed \f0\fs26 ?\ \ I don\'92t see that section 5.2 says anything about a mechanism for = escrowing keys. It talks about installing a private key into a router = over the protected channel. If the citation to 5.2 is about the = \'93such that it can be re-inserted\'94 part of the sentence, then I get = it. But the citation should move to the end of the sentence.\ \ p10, section 10 (nit)\ \ After\ familiarizing one's self with the capabilities of the router,\ operators are encouraged\ \pard\pardeftab720\partightenfactor0 \fs24 \cf0 \ suggest:\ \pard\pardeftab720\partightenfactor0 \fs26 \cf0 \ After\ familiarizing themselves with the capabilities of the router,\ operators are encouraged\ \ \ or\ \ After\ familiarizing one's self with the capabilities of the router,\ an operator is encouraged\ \ p11, section 10 (nit)\ \ employees that no longer need access to\ routers SHOULD be removed the router \ \ suggest\ \ employees that no longer need access to\ a router SHOULD be removed from the router \ \ or\ \ employees that no longer need access to\ a router SHOULD be removed from the router access [list]\ \ p11, section 10 (nit)\ \ The\ operator MUST ensure that installed CA certificate is valid.\ \ suggest:\ \ The\ operator MUST ensure that the installed CA certificate is valid.\ \ p14, section Appendix A\ \ x509v3-ecdsa-sha2-nistp256 [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6187"}}{\fldrslt \cf2 \ul RFC6187}}] = could be used for\ authentication.\ \ is that an example, or a recommendation?\ \ p15, section Appendix B (nit)\ \ that will generate the key pair for the algorithms noted in the main\ body of this document;\ \ the algorithms are not noted in the main body, but the end of section 1 = does cite RFC8208. \ \ the private key just generated to sign the certification request = with\ the algorithms specified in the main body of this document;\ \ the algorithms are not specified in the main body, but the end of = section 1 does cite RFC8208.\ \ p16, Appendix B\ \ Uses of \'93serial number\'94:\ \ the subject name and serial number for the router. The CA needs = this\ and\ CSR you sent; the certificate will include the subject name, serial\ number, public key, and other fields\ and\ Create CSR and sign CSR with private key, and; o Step 3: Send CSR\ file with the subject name and serial number to CA.\ \ The first of these seem to mean the BGP Identifier aka RouterID. As = said before, RFC4271 and RFC8209 use the term BGP Identifier.\ \ The second and third use of \'93serial number\'94 probably also mean BGP = Identifier aka RouterID (not the issued cert\'92s serial number).\ \ p17, section Appendix B (typo nit)\ \ way through GPsec-enabling the router.\ \ suggest:\ \ way through BGPsec-enabling the router.\ \ p17, section Appendix B\ \ To avoid having routers with expired certificates\ follow the recommendations in the Certification Policy (CP) = [{\field{\*\fldinst{HYPERLINK = "https://tools.ietf.org/html/rfc6484"}}{\fldrslt \cf2 \ul RFC6484}}]\ \ you could also mention section 9.1.\ }= --Apple-Mail=_AC30B402-86BE-46EF-89E0-0204650424D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 14, 2017, at 10:33 AM, Sandra Murphy wrote: >=20 > Speaking as wg co-chair >=20 > Please, wg, do take a look at the comments attached. This draft was = requested by the operators and is important. >=20 > Some of the comments are about substance. Those at the very least = must be considered by the wg. >=20 > Please take advantage of focused attention and close proximity at the = IETF meeting to discuss. =20 >=20 > I unfortunately can not be there to button hole people and shove = printouts into their hands. >=20 > =E2=80=94Sandy, speaking as wg co-chair >=20 >> On Nov 5, 2017, at 9:25 PM, Sandra Murphy wrote: >>=20 >> I=E2=80=99m attaching some comments and questions I found in the -14 = version. >>=20 >> =E2=80=94Sandy >>=20 >> >>=20 >>> On Oct 20, 2017, at 1:04 PM, Sean Turner wrote: >>>=20 >>> Chris, >>>=20 >>> This version includes changes to address Oliver=E2=80=99s and = Sriram=E2=80=99s comments. >>>=20 >>> spt >>>=20 >>>> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote: >>>>=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 WG of = the IETF. >>>>=20 >>>> Title : Router Keying for BGPsec >>>> Authors : Randy Bush >>>> Sean Turner >>>> Keyur Patel >>>> Filename : draft-ietf-sidr-rtr-keying-14.txt >>>> Pages : 17 >>>> Date : 2017-10-20 >>>>=20 >>>> Abstract: >>>> BGPsec-speaking routers are provisioned with private keys in order = to >>>> sign BGPsec announcements. The corresponding public keys are >>>> published in the global Resource Public Key Infrastructure, = enabling >>>> verification of BGPsec messages. This document describes two = methods >>>> of generating the public-private key-pairs: router-driven and >>>> operator-driven. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-14 >>>>=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 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>=20 --Apple-Mail=_AC30B402-86BE-46EF-89E0-0204650424D8-- From nobody Tue Nov 14 18:07:29 2017 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 924E31200CF; Tue, 14 Nov 2017 18:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 DAj_x2EdYDip; Tue, 14 Nov 2017 18:07:24 -0800 (PST) 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 841E9126D73; Tue, 14 Nov 2017 18:07:24 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DF0CD28B0041; Tue, 14 Nov 2017 21:07:23 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1913A1F8036; Tue, 14 Nov 2017 21:07:22 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> Date: Tue, 14 Nov 2017 21:07:20 -0500 Cc: Sandra Murphy , Christopher Morrow , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org, sidr list Content-Transfer-Encoding: quoted-printable Message-Id: <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:07:27 -0000 Wellllll. The mail archive does not seem to show attachments. For me. I see do = see attachments on other messages. It would be nice to know if anyone has seen attachments on my messages = in the last few weeks. At any rate, for the mail archive, the comments are copied below the = signature. =E2=80=94Sandy Points that might get lost in the long detailed list that follows: 1. RFC4271 (and RFC6286) and RFC8209 use the term =E2=80=9CBGP = Identifier=E2=80=9D. The main text says RouterID and the Appendix B = says =E2=80=9Cserial number=E2=80=9D. I believe both are talking about = what RFC8209 calls the =E2=80=9CBGP Identifier=E2=80=9D. Most of the = tech sites say router ID or router-id or routerid or RID or some such. = But I think consistency with the referenced text would be good. 2. I was initially confused by the text in various places that talks = about the operator adding the AS and RouterID (sic) and sends to the CA. = I thought that meant the operator adds those to the CSR, which would be = hard since the CSR is signed. This occurs a couple of places. I = suggest a sentence early on that says the router certificate includes = the AS and router identifier but the CSR does not include such fields, = so the operator must include the AS and routerID when it sends the CSR = to the CA. 3. =E2=80=9Ccorresponds=E2=80=9D - there are several places that say = the certificate must be validated to prove that the public key = corresponds with the private key. The main body does not say how that = correspondence is validated. The appendix suggests that the operator = could validate the signature on the CSR with the returned router cert in = order to validate the key. (a) When the operator generated the = public/private key pair, why not just do a comparison to the generated = public key, presuming it was retained? (b) When the operator passed the = CSR generated by the router to the CA, why not validate the public key = before sending it to the CA? The public key in the returned router = certificate could subsequently be validated by a comparison, presuming = the public key was retained. (c) When the router is supposed to = validate the public key of the router cert it receives, and the operator = generated the public/private key pair, it does not have a copy of the = CSR to validate the correspondence. Took me a bit to realize the router = could sign just any old bit of bytes and then validate the signature = with the received router cert. Right? 4. =E2=80=9Ccorresponds=E2=80=9D again - there=E2=80=99s no mention of = a router verifying that the router cert it receives has an AS that is = configured on the router. There are lots of other checks and double = checks - why not this one? And if the router has multiple ASs and = multiple CSRs have been generated (either by the router or by the = operator), then the router uses the received router certificate to = associate the AS with the public/private key pair, so it knows which = private key to use over which session. Right? 5. Section 8 on =E2=80=9CAdvanced Deployment Scenarios=E2=80=9D talks = about routers that already have pre-installed keys (with mentions of = types of crypto that are not known to me, and I did not dig up the refs, = so I might be missing something here). The first paragraph talks about = =E2=80=9Cpre-installed key material=E2=80=9D. I could understand why = these pre-installed keys might be useful in authenticating the router = directly to the CA. The =E2=80=9Cburdens=E2=80=9D 1 and 2 also talk = abut =E2=80=9Ckey material=E2=80=9D. It did not look to me like the = =E2=80=9Ckey material=E2=80=9D in 1 and 2 are talking about these = =E2=80=9Cpre-installed=E2=80=9D keys. But I admit to being very = confused by the way the term is used. 6. Section 5.2.1 is titled =E2=80=9DUsing PKCS#8 to Transfer Public = Key=E2=80=9D. The text talks about using PKCS #8 in RFC5958, which = allows for including both the public and private key. But the text of = that section is talking about using PKCS #8 to transmit the private key = to the router. I presume the title should be Using PKCS#8 to Transfer = Private Key 7. There is an early assumption that all the communication between the = operator and the router is over a protected channel. Section 5.2.1 = suggests using a CMS SignedData to transmit the PKCS#8. RFC5958 = suggests several different =E2=80=9CCMS protecting content types=E2=80=9D = for the PKCS#8 - EncryptedData, EnvelopedData, etc. I presume that the = encrypted versions are not used here because the protected channel = ensures confidentiality. So (a) Appendix A talks about the key strength = to be used for the different crypto algorithms (encryption, key = exchange, =E2=80=A6). That=E2=80=99s a big hint that the channel should = provide the related security protections. I think it would be good to = explicitly state the protections the protected channel must provide: = =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity and replay protection=E2=80=9D. (b) if the = protected channel provides authentication and integrity, why is the = protection of the CMS SignedData needed? One possible reason follows -> = (c) The AS EE certificate has an AS extension, not an IP extension, I = presume. So the AS EE certificate would be a second way for the router = to associate a private key with an AS and an appropriate BGP session = (see my comment 3c above). But this applies only when the operator = generated the public/private key pair. 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines = several types of content, e.g., signed-data, enveloped-data, = signed-and-enveloped-data, etc. Is there any reason to specify which = type? Is it operator choice? 9. The term =E2=80=9Coperator=E2=80=9D is used to talk about = carbon-based units (who are forgetful), ISP organizations (who peer with = other operators), ASs (who have an AS EE certificates) and management = system stations (that receive CSRs from the router). It was a bit = unsettling, but after multiple reads through I=E2=80=99m getting used to = it. I=E2=80=99m not sure I could suggest a term that would fit all = those uses. Perhaps network operators (the ones with DNA) identify = personally with all those uses and think of their person in all cases. = =E2=80=9CI am the AS=E2=80=9D, =E2=80=9CI am the peering entity=E2=80=9D, = =E2=80=9CI am the management of the network=E2=80=9D, etc. 10. I do not understand the last two paragraphs of section 7 at the = bottom of page 6. It sounds to me like they are out of place, like they = belong elsewhere in the text. 11. There are some occurrences of =E2=80=9Cmust=E2=80=9D and only a few = of =E2=80=9CMUST=E2=80=9D - the draft is standards track, so how much of = the described behaviors are mandatory? 12. Some consistency nits - PKCS sometimes followed by a space, = sometimes not. protected channel, secure channel, communications = channel, protected session, SSH session, . . . =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OK, so on to the detailed comments, sequentially through the document p3, section 1: two methods to provision new and existing routers. The methods described involve the operator configuring the two end points and acting as the intermediary. What are the two endpoints? The router and the management station? The = router and the CA? I can imagine the operator configuring the = management station, but not the CA. I can imagine the operator acting = as the intermediary between the router and the CA, but not between the = router and the management station. p3, section 1: (nit) [RFC8208] specifies the algorithms used to generate the signature. If I read correctly, =E2=80=9Cthe=E2=80=9D signature in this text would = be the signature on the PKCS#10. =20 suggest: [RFC8208] specifies the algorithms used to generate the PKCS#10 signature. p4, section 2 See Appendix A for security considerations for this channel. I think it is important to say what security protection are required for = this protected channel. Appendix A talks about the strength of the key used in the various = crypto algorithms. I think a sentence something like the following would be useful here or in = Appendix A. =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity=E2=80=9D and replay protection.=E2=80=9D p4, section 4 (nit) appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. suggest: appropriate RPKI Trust Anchor Certificate (TA Cert) in the router. or appropriate RPKI Trust Anchor=E2=80=99s Certificate (TA Cert) in the = router. p4, section 4 The operator also configures the Autonomous System (AS) number to be used in the generated router certificate. This may be the sole AS configured on the router, or an operator choice if the router is configured with multiple ASs. There=E2=80=99s a hint here that the operator configures the router to = generate just one router certificate. RFC8209 allows the router certificate to have one or more ASs, but = recommends that there be multiple router certificates with one AS each. = Does this paragraph intend to limit a router to one router certificate = or just to limit the router to one AS per router certificate? I have = questions later about what happens if the router wants a router = certificate for each of multiple ASs. Perhaps =E2=80=9CA router with multiple ASs can be configured with = multiple router certificates=E2=80=9D, maybe also =E2=80=9Cby following = the process of this document for reach desired certificate=E2=80=9D. The operator configures or extracts from the router the BGP RouterID RFC4271 and RFC8209 say =E2=80=9CBGP Identifier=E2=80=9D. OSPF uses = RouterID, and lots of C/J commands use RouterID, or router-id, or router = id, or RID, or . . . But consistency with the referenced specs would a = good thing. p4, section 5 I think it would be great to add a sentence here explaining that the = PKCS#10 (CSR) format does not include the AS and RouterID (sic). = Therefore, the operator must transmit the AS and RouterID (sic) as well = when it sends the CSR to the CA. =20 That sentence applies to both the router generated keys and the operator = generated keys, so maybe it could go here. The PKCS#10 format does not include the AS and RouterID for the router = certificate. Therefore, the operator must include the AS it has chosen = for the router and the RouterID when it sends the CSR to the RPKI CA. That should be a MUST, shouldn=E2=80=99t it? p5, section 5.1 The operator adds the chosen AS number and the RouterID to send to the RPKI CA for the CA to certify. My first reading was that the text meant the AS and RouterID were added = to the CSR. First, that=E2=80=99s not possible because of the = signature, unless there=E2=80=99s some key sharing going on. Second, = that=E2=80=99s not possible because the CSR format does not include the = AS and RouterID. Hence my comment above. suggest: The operator includes the chosen AS number and the RouterID when it = sends the CSR to p4, section 5.1 (nit) NOTE: If a router was to communicate directly with a CA to have the suggest: NOTE: If a router were to communicate directly with a CA to have the p5, section 5.2 and adds the chosen AS number and RouterID to be sent to the RPKI CA for the CA to certify. suggest: and includes the chosen AS number and the RouterID when it sends the = CSR to the RPKI CA for the CA to certify. p5, section 5.2.1 section title =E2=80=9CUsing PKCS#8 to Transfer Public Key=E2=80=9D PKCS#8 in RFC5958 can transfer public keys. But the following text is = talking about transferring the private key to the router. =20 I think this title should be =E2=80=9CUsing PKCS#8 to Transfer Private = Key=E2=80=9D A private key encapsulated in a PKCS #8 [RFC5958] should be further encapsulated in Cryptographic Message Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity (EE) private key. Would =E2=80=9CA private key encapsulated in a PKCS #8=E2=80=9D be = followed by "OTOH, a private key that is not encapsulated in a = PKCS#8=E2=80=9D? :-) Suggest: A private key can be encapsulated in a PKCS #8 [RFC5958] and should = be further (or =E2=80=9Cis=E2=80=9D encapsulated or =E2=80=9Cshould be=E2=80=9D = encapsulated)=20 Section 3 suggests various ways to =E2=80=9Cexchange PKI-related = information with routers=E2=80=9D. Is this PKCS#8 just one more way, or = is it the recommended way? The intro to section 5 suggests that copy = and paste could also be used, but doesn=E2=80=99t say if that would be = copy and paste of the PKCS#8. If Section 5 is also talking about = straight copy and paste of the hex or the PEM block, then that=E2=80=99s = another alternative. RFC5958 discusses several =E2=80=9CCMS protecting content types=E2=80=9D = to protect the AsymmetricKeyPackage. I presume that the = encryption/enveloping content types are not needed because = confidentiality is being provided by the protected channel. But then = why use the CMS SignedData - would not the protected channel provide the = authentication and integrity needed? (But see potential reason below) [RFC5652] and signed with the AS's End Entity (EE) private key. Does it matter which AS=E2=80=99s EE cert the operator uses to sign the = PKCS#8? I presume that the AS must match an AS with which the router is = configured. Should the router check that? Does a router that is = configured with multiple ASs use this communication to tie the private = key to the appropriate AS & BGPsec session? =20 If the answer is yes to both questions, should those actions be = mentioned here? (I admit to being a bit dizzy here, but maybe the mapping of private = key to AS happens in the receipt of the router certificate.) =20 include in the SignedData the RPKI CA certificate and relevant AS's EE certificate(s). =20 Maybe this is the reason for using the SignedData - to be able to = include the AS=E2=80=99s EE cert and give the router the means to tie = the private key to the right AS. The router SHOULD verify the signature of the encapsulated PKCS#8 to ensure the returned private key did in fact come from the operator, Then shouldn=E2=80=99t it be signed with the operator=E2=80=99s personal = cert? :-) =20 include in the SignedData the RPKI CA certificate and relevant AS's EE certificate(s). Elsewhere (sections 6 & 7) it mentions including the entire cert chain. = Should that be mentioned here as well? p5, section 6 (nit) The operator uses RPKI management tools to communicate with the global RPKI system to have the appropriate CA validate the PKCS#10 request, sign the key in the PKCS#10 (i.e., certify it) and generated PKCS#7 response, as well as publishing the certificate in the Global RPKI. for symmetry, suggest: The operator uses RPKI management tools to communicate with the global RPKI system to have the appropriate CA validate the PKCS#10 request, sign the key in the PKCS#10 (i.e., certify it) and generate = a PKCS#7 response, as well as publish the certificate in the Global RPKI. p5, section 6=20 External network connectivity may be needed if the certificate is to be published in the Global RPKI. The previous sentence and the following paragraph do not hint that there = is any =E2=80=9Cif=E2=80=9D about the publication of the certificate. = Is there a case where the certificate is NOT =E2=80=9Cto be published in = the Global RPKI=E2=80=9D? p6, section 6 (nit) 2. Returns the certificate to the operator's management station, packaged in a PKCS#7 Needs a reference. RFC2315? In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7, and verify that the private key it holds corresponds to the returned public key. =E2=80=9Cit=E2=80=9D means the operator, right? You get to Appendix B before the verification of the correspondence is = explained. I think it should be explained here. The Appendix B says the operator should verify the signature on the = PKCS#10 CSR to verify the correspondence. But the operator generated = the key - can=E2=80=99t the correspondence be verified by checking the = certificate=E2=80=99s public key against the operator generated public = key (presuming the key was retained)? That seems too easy - I fear I am = missing some important part here. p6, section 7 The router SHOULD extract the certificate from the PKCS#7 and verify that the public key corresponds to the stored private key.=20 I think more needs to be said about how the correspondence would be = verified.=20 Appendix B says the operator should verify the signature on the PKCS#10 = with the certificate to verify the correspondence to the private key. = That would work for the router as well if the router generated the = PKCS#10, but not if the operator generated the key pair and the PKCS#10. = But the router could sign any random bunch of bits and verify the = signature with the certificate to verify the correspondence. Should = those things be said? Also, in the router-driven method, the router can verify the = correspondence simply by matching the certificate=E2=80=99s public key = with one of the router=E2=80=99s stored public keys. (Right? What am I = missing here?) Should the router also verify that the AS mentioned in the returned = router certificate is an AS with which it is configured? For a router that is configured with multiple ASs, is this where the = router ties the private key to the AS & BGPsec session with which the = private key should be used? The last two paragraphs of section 7 confuse me. Even if the operator cannot extract the private key from the router, this signature still provides a linkage between a private key and a router. That is the operator can verify the proof of possession (POP), as required by [RFC6484]. What is =E2=80=9Cthis signature=E2=80=9D? And there=E2=80=99s been no = mention in this section of extracting the private key from the router. This sounds to me like it belongs in section 5.1, maybe after:=20 =E2=80=9Cto= sign the PKCS#10 with the private key. Once generated, the PKCS#10 is returned to the operator over the protected channel. And then: NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8, permits more advanced configurations where the entity that generates the keys is not the direct CA. Maybe this belongs in section 5.2.1 where it is talking about the = PKCS#8? Even so, I=E2=80=99m not sure what Certificate this text references. = The AS EE cert? Both the router-driven method and the operator-driven method are not the = direct CA. Nowhere in this draft does it mention the CA generating the = keys. So the entire draft is one of these =E2=80=9Cadvanced = configurations=E2=80=9D. What am I missing here? p7, section 8 (nit) Transport" [RFC7030] or the original CMC transport protocol's Is the possessive really needed here? I didn=E2=80=99t peruse the = RFC5273 thoroughly, but I can see that it defines a number of transport = methods, so maybe there is a =E2=80=9CCMC transport protocol=E2=80=99s = X=E2=80=9D missing here. p7, section 8 This section uses =E2=80=9Ckey material=E2=80=9D several places. But = I=E2=80=99m not certain each use is talking about the same key material. When the operator first establishes a secure communication channel between the management system and the router, this pre-installed key material is used to authenticate the router. So the router gets keys as part of the manufacturing, where the = =E2=80=9Cpre-installed key material=E2=80=9D can be used in = communication with the operator. I can see that this might make it easier for the router to communicate = directly with the CA and authenticate itself using these keys. But = section 5.1 notes that the CA has no way to authenticate the router. I = don=E2=80=99t know that the pre-installed key material could provide = that way to authenticate the router, without the participation of the = operator at some point. The operator burden shifts here to include: I=E2=80=99m not sure how to read this. Maybe =E2=80=9CThe operator = burdens that shift here can/will include=E2=80=9D. I=E2=80=99m also not sure if both 1 and 2 are presumed to be = shifted/lifted, or if it is either. 1. Securely communicating the router's authentication material to the CA prior to operator initiating the router's CSR. CAs use authentication material to determine whether the router is eligible to receive a certificate. Authentication material at a minimum includes the router's AS number and RouterID as well as the router's key material, but can also include additional information. Authentication material can be communicated to the CA (i.e., CSRs signed by this key material are issued certificates with this AS and RouterID) or to the router (i.e., the operator uses the vendor-supplied management interface to include the AS number and routerID in the router-generated CSR). Who is doing the communicating in =E2=80=9Csecurely communicating to the = CA=E2=80=9D and =E2=80=9Ccan be communicated to the CA=E2=80=9D? In the = following paragraph, the text says =E2=80=9Cthe router is communicating = directly with the CA=E2=80=9D - is the communication in this part 1 text = going from the router to the CA? What is the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D? I could = read it both ways: The paragraph above says that the pre-installed key material is used to = authenticate the router, so maybe the =E2=80=9Crouter=E2=80=99s key = material=E2=80=9D is the pre-installed key material. The text says that = the CA =E2=80=9Cuses=E2=80=9D the authentication material, which = includes the router=E2=80=99s key material, to determine whether to = issue the certificate. I don=E2=80=99t know how the pre-installed key = material could assure the CA that the router could be issued a cert, = without some coordination with the operator about that particular key = material. Then the text says =E2=80=9CCSRs signed by this key material=E2=80=9D = which implies that the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D = is the public/private key pair. So I=E2=80=99m not certain what is going on here, or how the = pre-installed key material is helping. Once configured, the operator can begin the process of enrolling the router. =20 What does =E2=80=9Conce configured=E2=80=9D mean? configuring the = router-operator protected channel? Doing the communication of = authentication material in 1 and 2 above? Configuring the router with = AS and RouterID? Because the router is communicating directly with the CA, there is no need for the operator to retrieve the PKCS#10 from the router or return the PKCS#7 to the router as in Section 6. Note = that the checks performed by the router, Section 5 says the router returns the PKCS#10 to the operator. Section 7 says the operator sends the PKCS#7 to the router and the = router performs checks. suggest: Because the router is communicating directly with the CA, there is no need for the operator to retrieve the PKCS#10 from the router as in Section 5 or return the PKCS#7 to the router as in = Section 7. Note that the checks performed by the router in Section 7, When a router is so configured the communication with the CA SHOULD be automatically re-established what does =E2=80=9Cso configured=E2=80=9D mean here? configured with = pre-installed key material? configured by the operator with AS and = RouterID? p8, section 9.1 (nit) just for symmetry: 4. Use some other kind of automated process to search for and track suggest: 4. The operator uses some other kind of automated process to search = for and track p8, section 9.1 Regardless of the technique used to track router certificate expiry times, it is advisable to notify additional operators in the same organization =E2=80=9Cnotify additional operators=E2=80=9D =E2=80=94 In addition to = what? or after what? I think you mean =E2=80=9Cmultiple=E2=80=9D operators, or I = misunderstand. p9, section 9.3 (nits) certificate to the router), and distributing the status takes time Not sure what you mean by =E2=80=9Cstatus=E2=80=9D that needs to be = distributed. Are you talking about distributing the revocation = =E2=80=9Cstatus=E2=80=9D in the CRL? Keeping the router operational and BGPsec-speaking is the ideal goal, but if operational practices do not allow this then reconfiguring the router to disabling BGPsec is likely preferred to bringing the router offline. suggest: router to disable BGPsec is likely preferred to bringing the router p10, section 9.4 To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to inserted via a protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This lets the operator escrow the old private key via the mechanism used for operator-generated keys, see Section 5.2, such that it can be re- inserted into a replacement router. The topic here is routers that won=E2=80=99t allow off-loading of their = keys. =20 =E2=80=9Crouters SHOULD allow the private BGPsec key to inserted=E2=80=9D is the router that is doing the allowing the old, soon to be replaced = routers, or the newly installed routers? =E2=80=9Cto inserted=E2=80=9D - where? - in the newly installed = router or in the management station? =E2=80=9CThis lets the operator escrow the old private key=E2=80=9D - = sounds like the old router is allowing the private key to be =E2=80=9Cinse= rted in=E2=80=9D (exported to?) the management station. Right? Is there a suggestion of how to get the routers to allow export of the = key, which is currently not allowed? I don=E2=80=99t see that section 5.2 says anything about a mechanism for = escrowing keys. It talks about installing a private key into a router = over the protected channel. If the citation to 5.2 is about the =E2=80=9C= such that it can be re-inserted=E2=80=9D part of the sentence, then I = get it. But the citation should move to the end of the sentence. p10, section 10 (nit) After familiarizing one's self with the capabilities of the router, operators are encouraged suggest: After familiarizing themselves with the capabilities of the router, operators are encouraged or After familiarizing one's self with the capabilities of the router, an operator is encouraged p11, section 10 (nit) employees that no longer need access to routers SHOULD be removed the router=20 suggest employees that no longer need access to a router SHOULD be removed from the router=20 or employees that no longer need access to a router SHOULD be removed from the router access [list] p11, section 10 (nit) The operator MUST ensure that installed CA certificate is valid. suggest: The operator MUST ensure that the installed CA certificate is valid. p14, section Appendix A x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for authentication. is that an example, or a recommendation? p15, section Appendix B (nit) that will generate the key pair for the algorithms noted in the main body of this document; the algorithms are not noted in the main body, but the end of section 1 = does cite RFC8208. =20 the private key just generated to sign the certification request with the algorithms specified in the main body of this document; the algorithms are not specified in the main body, but the end of = section 1 does cite RFC8208. p16, Appendix B Uses of =E2=80=9Cserial number=E2=80=9D: the subject name and serial number for the router. The CA needs this and CSR you sent; the certificate will include the subject name, serial number, public key, and other fields and Create CSR and sign CSR with private key, and; o Step 3: Send CSR file with the subject name and serial number to CA. The first of these seem to mean the BGP Identifier aka RouterID. As = said before, RFC4271 and RFC8209 use the term BGP Identifier. The second and third use of =E2=80=9Cserial number=E2=80=9D probably = also mean BGP Identifier aka RouterID (not the issued cert=E2=80=99s = serial number). =20 p17, section Appendix B (typo nit) way through GPsec-enabling the router. suggest: way through BGPsec-enabling the router. p17, section Appendix B To avoid having routers with expired certificates follow the recommendations in the Certification Policy (CP) [RFC6484] you could also mention section 9.1. > On Nov 14, 2017, at 10:36 AM, Sandra Murphy wrote: >=20 >=20 >=20 > Sorry, the reply did not pick up the original attachment. >=20 > Attached here. >=20 > Let me know if there are problems reading the comments. >=20 > =E2=80=94Sandy >=20 > >=20 >> On Nov 14, 2017, at 10:33 AM, Sandra Murphy = wrote: >>=20 >> Speaking as wg co-chair >>=20 >> Please, wg, do take a look at the comments attached. This draft was = requested by the operators and is important. >>=20 >> Some of the comments are about substance. Those at the very least = must be considered by the wg. >>=20 >> Please take advantage of focused attention and close proximity at the = IETF meeting to discuss. =20 >>=20 >> I unfortunately can not be there to button hole people and shove = printouts into their hands. >>=20 >> =E2=80=94Sandy, speaking as wg co-chair >>=20 >>> On Nov 5, 2017, at 9:25 PM, Sandra Murphy wrote: >>>=20 >>> I=E2=80=99m attaching some comments and questions I found in the -14 = version. >>>=20 >>> =E2=80=94Sandy >>>=20 >>> >>>=20 >>>> On Oct 20, 2017, at 1:04 PM, Sean Turner wrote: >>>>=20 >>>> Chris, >>>>=20 >>>> This version includes changes to address Oliver=E2=80=99s and = Sriram=E2=80=99s comments. >>>>=20 >>>> spt >>>>=20 >>>>> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote: >>>>>=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 WG of = the IETF. >>>>>=20 >>>>> Title : Router Keying for BGPsec >>>>> Authors : Randy Bush >>>>> Sean Turner >>>>> Keyur Patel >>>>> Filename : draft-ietf-sidr-rtr-keying-14.txt >>>>> Pages : 17 >>>>> Date : 2017-10-20 >>>>>=20 >>>>> Abstract: >>>>> BGPsec-speaking routers are provisioned with private keys in order = to >>>>> sign BGPsec announcements. The corresponding public keys are >>>>> published in the global Resource Public Key Infrastructure, = enabling >>>>> verification of BGPsec messages. This document describes two = methods >>>>> of generating the public-private key-pairs: router-driven and >>>>> operator-driven. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>>>=20 >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-14 >>>>>=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 >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>=20 >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >=20 From nobody Wed Nov 15 23:59:59 2017 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 E3E7D126BFD; Wed, 15 Nov 2017 23:59:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151081919187.28369.12154628810347674400@ietfa.amsl.com> Date: Wed, 15 Nov 2017 23:59:51 -0800 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 07:59: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 WG of the IETF. Title : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Daniel Shaw Filename : draft-ietf-sidr-rpki-validation-reconsidered-09.txt Pages : 22 Date : 2017-11-15 Abstract: This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. Where the procedure specified in RFC 6487 requires that Resource Certificates are rejecting entirely if they are found to over-claim any resources not contained on the issuing certificate, the validation process defined here allows an issuing Certificate Authority to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. This choice is signalled by form of a set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a Trust Anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487 Furthermore this document provides an alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication requested) validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-09 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rpki-validation-reconsidered-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-09 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 Nov 16 00:44:35 2017 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 61AB1129A84 for ; Thu, 16 Nov 2017 00:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 TmYMSF_LfzpK for ; Thu, 16 Nov 2017 00:44:31 -0800 (PST) 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 88838129566 for ; Thu, 16 Nov 2017 00:44:31 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eFFmf-0005Ir-GX for sidr@ietf.org; Thu, 16 Nov 2017 09:44:30 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-250.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eFFmd-00062D-LT; Thu, 16 Nov 2017 09:44:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tim Bruijnzeels In-Reply-To: <151081919187.28369.12154628810347674400@ietfa.amsl.com> Date: Thu, 16 Nov 2017 16:44:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <151081919187.28369.12154628810347674400@ietfa.amsl.com> To: sidr X-Mailer: Apple Mail (2.3273) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071965b1375632d4af3d28ca24defb61afc5 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-09.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:44:33 -0000 Dear WG, This version was uploaded because looking at this on-line proved more = convenient for IESG review, as opposed to the version of this that I = sent as an email attachment. We have a had a discussion about remaining = DISCUSS items and a -10 version is coming soon as well. Possibly still = before I board my plane home tomorrow, otherwise early next week. Kind regards, Tim > On 16 Nov 2017, at 15:59, internet-drafts@ietf.org wrote: >=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 WG of the = IETF. >=20 > Title : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Daniel Shaw > Filename : = draft-ietf-sidr-rpki-validation-reconsidered-09.txt > Pages : 22 > Date : 2017-11-15 >=20 > Abstract: > This document specifies an alternative to the certificate validation > procedure specified in RFC 6487 that reduces aspects of operational > fragility in the management of certificates in the RPKI, while > retaining essential security features. >=20 > Where the procedure specified in RFC 6487 requires that Resource > Certificates are rejecting entirely if they are found to over-claim > any resources not contained on the issuing certificate, the > validation process defined here allows an issuing Certificate > Authority to chose to communicate that such Resource Certificates > should be accepted for the intersection of their resources and the > issuing certificate. >=20 > This choice is signalled by form of a set of alternative Object > Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and > AS Identifiers, and certificate policy for the Resource Public Key > Infrastructure (RFC 6484). It should be noted that in case these > OIDs are not used for any certificate under a Trust Anchor, the > validation procedure defined here has the same outcome as the > procedure defined in RFC 6487 >=20 > Furthermore this document provides an alternative to ROA (RFC 6482), > and BGPSec Router Certificate (BGPSec PKI Profiles - publication > requested) validation. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside= red/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-0= 9 > = https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rpki-validation-reco= nsidered-09 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-validation-recons= idered-09 >=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 >=20 From nobody Thu Nov 16 00:46:14 2017 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 7348B126BFD; Thu, 16 Nov 2017 00:46:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, Chris Morrow , aretana.ietf@gmail.com, sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151082197246.28329.17645675689871912295.idtracker@ietfa.amsl.com> Date: Thu, 16 Nov 2017 00:46:12 -0800 Archived-At: Subject: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-09: (with COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:46:12 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for resolving my DISCUSS points. I note that there is new explanatory text in the abstract. I suggest similar text be added in an introductory section in the body, since readers are known to sometimes skip the abstract. I am leaving my other comments below for documentation purposes; I leave it to the authors and shepherd to decide if they are sufficiently addressed. ------------------- Substantive: - General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)? - 4.2.4.4: -- "Any extension not thus identified MUST NOT appear in certificate x." (Repeats multiple times) That seems to prevent future extensibility. Is that the intent? -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a CRL issued by the CA represented by certificate x-1" Is this intended as a requirement to check CRLs? If so, please say that explicitly. Editorial: -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he - 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical." "... and if present..." seems redundant, since the previous clause said one MUST be present. - 4.3.4.3: "... values are NOT supported..." a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords. - 4.2.4.4 : -- "Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]." The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc. are already covered in 5280. - - "...certificate MUST contain all extensions defined in section 4.8 of [RFC6487] that must be present." That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent. -- "all extensions defined in section 4.8 of [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be present. " It would be more reader-friendly to mention what extensions are defined in 4.8.9. -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:" Inconsistent voice. -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension." That seems identical to the first bullet. Should it has said "AS Address Delegation extension"? From nobody Tue Nov 28 01:04:25 2017 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 ED9EA126CD6 for ; Tue, 28 Nov 2017 01:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 WstVloEu20hp for ; Tue, 28 Nov 2017 01:04:21 -0800 (PST) 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 55C2512421A for ; Tue, 28 Nov 2017 01:04:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 26C0DB80C87; Tue, 28 Nov 2017 01:04:11 -0800 (PST) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128090411.26C0DB80C87@rfc-editor.org> Date: Tue, 28 Nov 2017 01:04:11 -0800 (PST) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 09:04:23 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5187 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 7.1 Original Text ------------- encompass Given two IP address and AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X. Corrected Text -------------- encompass Given two IP address or two AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 01:17:41 2017 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 5B7B4126CD8 for ; Tue, 28 Nov 2017 01:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 T5_yLtDfmVbg for ; Tue, 28 Nov 2017 01:17:33 -0800 (PST) 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 B961112421A for ; Tue, 28 Nov 2017 01:17:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 92DE6B80D4C; Tue, 28 Nov 2017 01:17:23 -0800 (PST) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128091723.92DE6B80D4C@rfc-editor.org> Date: Tue, 28 Nov 2017 01:17:23 -0800 (PST) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC6487 (5188) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 09:17:39 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5188 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 7.1 Original Text ------------- Validation of a certificate's resource extension in the context of a certification path (see Section 7.2 entails that for every adjacent Corrected Text -------------- Validation of a certificate's resource extension in the context of a certification path (see Section 7.2) entails that for every adjacent Notes ----- The closing parenthesis is missing. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 02:01:59 2017 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 8EB8B1293E1 for ; Tue, 28 Nov 2017 02:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.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 6TvkEfNhJ9xq for ; Tue, 28 Nov 2017 02:01:54 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0055.outbound.protection.outlook.com [104.47.124.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B44126E3A for ; Tue, 28 Nov 2017 02:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FDWpkHRn1Afv9+K6T7hsd4M4OL+ThtokNWlcY1YzJtw=; b=REEXtpguti2lLxB5sVZU966OqlFtz9CVLFR+KQag4/Od8OdSe6wVjRtpPVn0HA+2b5khvCo16hyYqIoIdNhLqtNa0A8Z7x8nOaRLZCUttnLXwP2lAWbasuL+V/K9SYqJt5mUpuSOhRoubt51KM3BipLM1u9V87FswSDMMYCezd8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from 2001-44b8-1121-1a00-f198-572d-d022-daff.static.ipv6.internode.on.net (2001:44b8:1121:1a00:f198:572d:d022:daff) by SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 10:01:44 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Geoff Huston In-Reply-To: <20171128090411.26C0DB80C87@rfc-editor.org> Date: Tue, 28 Nov 2017 21:01:33 +1100 Cc: George Michaelson , robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com, nmalykh@gmail.com, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> References: <20171128090411.26C0DB80C87@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [2001:44b8:1121:1a00:f198:572d:d022:daff] X-ClientProxiedBy: HK2PR0302CA0007.apcprd03.prod.outlook.com (2603:1096:202::17) To SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c57256c1-36d7-4f9a-43f6-08d536470a5d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 3:eELwt8lUweJkU3UTz1AI57Cf3IIDMLDKtYSlFgqSqkqs6PIyO4F2VghuuDQmGw1kbWG9cCQoMlr3pE4UF9Q8iCzQWxQmmNENsMSZgrX1SM//lv86tcNQZf+T2yG/T8urTLXFf2Y5Ld1gf7YBEsHmxG6k/jaSLyJWWHwDW+SNc7kkqqWpKHKlCcenYq4VHC0VHOGRQiOnxo/3KEQfnWOsa3Jp/H4vi/ujGQ8eS38J3LhU4yIXDMDxjgxVL91VyCkv; 25:5/YSTCj3oUQStNk68x2aMHH4Dy8VO8DcNgnlBCHPjFDE5LlWLK+wiW7DbFNV+YvE3+jkBGEyneRHJQTR9EODomoR4eGiPtX5u1y1zdE7VKWrikxQRsl58RegEToMmmsdEqAQw7m6+cNnbhAuW2FrO+BenBh2L1a1A7nEZelrenxaVc74nqyrpJOcsBFXdnjpNF78uafUEPlltFv46HNTNHoUTxN/srVadR92k8rqdXzuUGh3hkYOwQX/LhOGzo27rP1Ux5hmkMu9A3nymp7CiY4n7FarJknnsSI1BjssZxqfATu9YG6VZS7q/6t+Fu+NKGft37PQfHkJdqGcQDXcgA==; 31:xK2+CKCIiWHsGJaebYyxU9PD63CKvNf5OSM38RxDLcmCwYmt/DroQOYs/EBzs5d4AyYLJVvEupDL5x0Y3O+afdYAOTHQ4GMNTir0eGn852XrvCr4MqgJmRV2k+tU9PtnspH0EyVroyAi0d6ItUAmJQNXQT7wvRH13rfTF2usMEYn6qsfMPDo0nkDGcsZ3xYwZnDy6Ox5nBiwHziClxnER3baCVQbTBk0+M4PZ520l8w= X-MS-TrafficTypeDiagnostic: SG2PR04MB0695: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(201703131423075)(201703061421075)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011); SRVR:SG2PR04MB0695; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 4:ZvrkpbuwbPbymLce6JikqHGaI6L1f3bFz6xDjkPcfsksQz1SpjajdC5mxqUWc8TsLSvMy7IaAgLJkUW6H3TRV7erId2Mlr9j9TVGN4AP8EbPuQwCavUKUkJ+9yCZ17GYEgBoXvV98eIH1F7M8t1rHJ6bu4FKdSBiJOX7BVqqP/TE4qYQrRZa9ReSmxi7CHqQkkCFsT5eGLP2sVIk/lBE7D6641g5DWCpLpRtEHLcrlj6/6RMk9RMO38P3RY95zU64AFd62V4mIvBRHtvCCPJ65BaW5F4c7FLcQA169GEgQAfttv24o5F8dhMNzlV4uln X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(199003)(189002)(24454002)(39060400002)(7736002)(106356001)(47776003)(5660300001)(68736007)(53546010)(6506006)(8936002)(8676002)(50466002)(36756003)(50226002)(508600001)(6246003)(76176999)(2950100002)(6486002)(33656002)(6306002)(305945005)(4326008)(50986999)(53936002)(6916009)(229853002)(101416001)(966005)(6116002)(1720100001)(57306001)(6666003)(97736004)(25786009)(86362001)(105586002)(23726003)(83716003)(52396003)(81156014)(6512007)(8746002)(81166006)(189998001)(2906002)(52116002)(82746002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR04MB0695; H:2001-44b8-1121-1a00-f198-572d-d022-daff.static.ipv6.internode.on.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SG2PR04MB0695; 23:wFV4Tv9obF+KMzNl3Bw95w1i76KfH72NTF5UxCX6a?= =?us-ascii?Q?YyBdMUI0IGSVgWdDQVo7IdyUe+8Qc2v3ik+KUE9qXjxu75CW99a3Iv1EzOTp?= =?us-ascii?Q?T/bqVx3aGEoUAB7xqQhssxjVg2YkR5BL49LbtYGdp9NhZ1rh8n2LjTp+uhQw?= =?us-ascii?Q?jRzYui7paYdH6gfKfKxyLwfa4wJRHjLfpaSBLzBwVi5zCC5P9xFETKLh7G7q?= =?us-ascii?Q?dapN+XmZQdaZZgYWQ6LNxrjj7OZ0YS7ap30OgpKrOUcIotHcNpPRtHor1tOT?= =?us-ascii?Q?6CQUfppfoKSAq3Wo6c8UWUVqicWlfwYtFJv1XSElnrInHUHFybZRMsEwuAeg?= =?us-ascii?Q?EZU1CksRu1fMEDJ+T9SaPBiXy2Dt96dgsueQKXa2RHnmzOD7yHPyd21M7wYk?= =?us-ascii?Q?PNfMgA/5I5khdQeC0iAe28GVMPfz87o+G6Z9vceooZJ2YnJwqP6x61OP+uuB?= =?us-ascii?Q?cvUz2+l1KgfjXqTNfaEn3l0X30LR7Eq/AjgZqOwRv71DK/3STiuIWnyZi1MB?= =?us-ascii?Q?X4oUgOLgk8DRdHkFMwaOy7Ikum36Ny/pIe40YFX9eekSIx/ejt2pjtocPd7B?= =?us-ascii?Q?v3oq9RHiugaQ84dAKeLLjw8YNAeuyW7qtLWvMH0Vc8KQr3/2R4ydWnO6TBsy?= =?us-ascii?Q?zrODaZJKLfLXROYH7EUr4eBiiHXJ4szhzO2E00XmcQfMzN5WFjlqa+FOz3BT?= =?us-ascii?Q?TBnM0VEm4PAb39B/mwIAK/dEo/5LGW1ZDWpm832gzfvQNaXBzaeTn5CWFvNq?= =?us-ascii?Q?FrK0Xalua2RNfZ9v0yb8rFb2uAO4Ksl2FfUkGSu+WQtotFkT3o2gIJ8zdPXu?= =?us-ascii?Q?fwagPP9xszMgORXkmA2Uo8lKQ8RqgCbHuHUGviER8iEdgSO3nT91cTjL0yz4?= =?us-ascii?Q?WsDvynyO5EgQ56eAy5rxLR2eB2uYeQ1xFRxvjqzSr8Y9ZeMVToTh9HtS+8N0?= =?us-ascii?Q?m/JqHbMoPhhLu4yKZAxU5xBYjoQLNmvYrR5zNhlsWTzsSagcCReteTlgpBp/?= =?us-ascii?Q?1lPdeb97Z4dgoEDDl1QtNDgtV46ixY76HU3OvOyxAnkpsR+WHGCkzIMF8H89?= =?us-ascii?Q?66hm1/y4wmTVQzi0Uh8oBNEvCqpAs7/2lMCV8H6n3LXo+4thhp/FwN1C1ywf?= =?us-ascii?Q?KAY5PlDRi+c54UwGskXQdLFm9yx47JXPgNNq+qmMRbQ/wF0DsH64eSJvUQlm?= =?us-ascii?Q?VEcbfB2teQarMS33EMFS6rQYZxwFhI+mtbHDGMJIgF3R3RhX4gbp/mlIvEqF?= =?us-ascii?Q?9gUNLv22tCLvdMjZkaTbPwvaB3SYawv5v87MMMH?= X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 6:jZgdQfyfj9ASrLXJr24YYa06NighDMKgGEvdLwzVnWix3RfsjK6GHQX+7XkAOyV8J2nJPHP8jPNVSbA5ppXxnrMXfXh/0Es7tv3nHB5XENYrfS5nzrh6nVwZSCmZci6H81tMCBwzkKCd7Kc5jMWHUAHgTeV7jVzPdczSWWnqMt6z4dcB6C5u6993Dj6/eG5RS59yZdRCanv+Kk5nD1QSnLmfP4U5dNSYRndTqL4ytHs1UYsJHkHj00lcb3jSu3pQyuea0cSvexoCqIAI25H1+p2Iksvb2pUIetJFG5nmEcXaWN41/vtI2jjRu3VeNDUqjJ4iewcUYRDmY69vGDD9xrxYM+1iGDozjQqUedI1z8E=; 5:niTCkiDn4YCDif0d9zaZQMNBA3kOHnEGae9ScFR04KjdppSTmXnrceiKCC3zws0GfUQ5qwSnacdeclI1uS0pRnWieZuuoUsLH2x2PuivEIWKmIQMYud60nkHuEjLfi126MGHdR7c0ST4qLX1wRazsKa/s9uQnOJqLn9DDPm5XmU=; 24:zvDWhRxBePHtiUBEEVgJrMSkA2bsprLsifv5/gvdLuo0/spOzBwd7NW9sGa+LoFFZBwlhIrCH8iB3nxqNIIRNYq0I7Tb+8czY2VbdjIp8Es=; 7:/7tf1JnpWYmngh34PfwOhJTQuU0Zy1lD3/S4ZcBxSVTiFjTKbZxAPSR93MB4KoUDgds/wCs4Po/gL+Yk9knGkRdcPJzlnAZPME8KiEbu0aIygJAZuAkRIDurKBF/MfKBe9TZM/4rtpamwgeAdAEEyco85scxBVIKMr5Iz+jpNMN0sW0TASmxIV0tuuhcgVJpBPkYNpKwlH+DtXaig9LVFQ8Hq2lWB93bXe9MKLtRPo3KJk1QbnGsjznZa8RaOSeA SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 10:01:44.8034 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c57256c1-36d7-4f9a-43f6-08d536470a5d X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR04MB0695 Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 10:01:57 -0000 Reject - in the context of resource certificates the resources may = contain both IP addresses _AND_ AS numbers.=20 > On 28 Nov 2017, at 8:04 pm, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5187 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 7.1 >=20 > Original Text > ------------- > encompass > Given two IP address and AS number sets, X and Y, X > "encompasses" Y if, for every contiguous range of IP addresses > or AS numbers elements in set Y, the range element is either > "more specific" than or "equal" to a contiguous range element > within the set X. >=20 >=20 > Corrected Text > -------------- > encompass > Given two IP address or two AS number sets, X and Y, X > "encompasses" Y if, for every contiguous range of IP addresses > or AS numbers elements in set Y, the range element is either > "more specific" than or "equal" to a contiguous range element > within the set X. >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Tue Nov 28 02:02:14 2017 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 D6C96126E3A for ; Tue, 28 Nov 2017 02:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.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 S2FGaadLhU5V for ; Tue, 28 Nov 2017 02:02:07 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0087.outbound.protection.outlook.com [104.47.124.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D201293D8 for ; Tue, 28 Nov 2017 02:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=99rnbwvKn7ozPKEPtZdMkBp5oxshFUJVhvebeBSHDqc=; b=k2daa5Hoh3B7XMeeZgMhw15FXl97jIMP64CoUc+SZsBY5uOC2cqMvCo8mdDXZ27NEMJeHIbAPKuj3ecFR62SxG8+2th1wOs4Rj1KB+2+uiyHaU6pDKze0LzvjOhULn9c0wojN6c0Ewi08wUX8Qo7UytxX6/RZO6qo/5A0O/MkjE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from 2001-44b8-1121-1a00-f198-572d-d022-daff.static.ipv6.internode.on.net (2001:44b8:1121:1a00:f198:572d:d022:daff) by SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 10:02:01 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Geoff Huston In-Reply-To: <20171128091723.92DE6B80D4C@rfc-editor.org> Date: Tue, 28 Nov 2017 21:02:00 +1100 Cc: George Michaelson , robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com, nmalykh@gmail.com, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171128091723.92DE6B80D4C@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [2001:44b8:1121:1a00:f198:572d:d022:daff] X-ClientProxiedBy: HK2PR0302CA0007.apcprd03.prod.outlook.com (2603:1096:202::17) To SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 681737b5-2f42-4bc7-e37d-08d536471320 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 3:0ox5IWgURR9sK3J990y12joKkl5J0jjbMRYJrk2t3i0PNcFJPgDQVmwIGNmIR9qqP5I8rSyWfcW9cdN/Scm0SzGvtyde7zf6FAT1EGKvIRr1vjoP1X05vJg97S+iY2okkjXZIqwWxaSmn+eBe16bwP4iT68PEaJdHC3YR6/461gRen8EQK5aNVCkHJWOMLTLYociS2pKo1f4M0g6gDvzxiI5WoDWIWa/sF6wVYlEzW8DC0XLSUFy11Grzv6b+OOI; 25:3LViveOA97msyaYupWkdQVJPkzvE241rtUqYNUGjU8X5BRTLstgMqMAO6FY5rl2PNVmxB42tF6i/UkVqiDpg20YfU7lrLrinZryegNnT2LCbS6iCe6V93KIFdmfFDsgl+3hAezO/k3MlJPeqMqfzW8fRhtdUyysXPjkm/CaGJtCbAqO5JUs/0qHvKRbqk+a78NNRnGo3oLligIKyDlwdAbgvWKu6k+DUYVG+jeWSv3TH78fgqVwKlzI5607AiOQzakLMuioVcEsDskNFtBBmjf8D3XcwovUQn9ouo1PT2yK2lwu94a71/Uu/DQZRL5FBJTLF3u+cZXfV5gadcGSYbw==; 31:1pEu/+EklFNBhWWtBzilIM0byv6wv8w+lsCLAHDfnYeKGZqp1Kzuc0REM3Djt1NT47sGUkSx2ztXIGbTRtIsd5Kc+ZJAGL0XEwf1zCLYOkW95Kj0TVzBVsOmLumL0nbMUo5NWETqLTSR+6VPJ7CI2xu79dKNiiHi3EgHRQrieuCcb5b2/9ewPBoiTI4dusZNgt1LQbPYTlHT66v3W7C0d9f3B6IrwZnyGsnzI4kB2r4= X-MS-TrafficTypeDiagnostic: SG2PR04MB0695: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(201703131423075)(201703061421075)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011); SRVR:SG2PR04MB0695; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 4:AqDo32Ux1SUqYW9xA0vr0vJfDAmfIP0fmOJiO09L1/yyiNr8RGppR7igaR2zUX52M4oyaz0IrQ3UIeOwhCSxDCO178oyhgSXElWsqD8WUfyr3AinznWBo/QS+BC4q4RSFC0Xo8fyyWR8OIZDetDAkMDD+fJvCYIjWq7PnqWllUVdRCNJ/q4C6V+mozhTCjLyjG2UfsgyNpyRkcynQJbErxOG6I2NiMDVxmkGyv4a+tBn4RTcVY+Q8lWes55mDS/tSqm/kzSRZChfCDoYMplWIA== X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(199003)(189002)(24454002)(39060400002)(7736002)(106356001)(47776003)(5660300001)(68736007)(53546010)(6506006)(8936002)(8676002)(50466002)(36756003)(50226002)(508600001)(6246003)(76176999)(2950100002)(6486002)(33656002)(6306002)(305945005)(4326008)(50986999)(53936002)(6916009)(229853002)(101416001)(966005)(6116002)(1720100001)(57306001)(97736004)(25786009)(86362001)(105586002)(23726003)(83716003)(52396003)(81156014)(6512007)(8746002)(81166006)(189998001)(2906002)(52116002)(82746002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR04MB0695; H:2001-44b8-1121-1a00-f198-572d-d022-daff.static.ipv6.internode.on.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SG2PR04MB0695; 23:v0AtS9/npIruye1j4FHY0fS84OP6hOlmhcq8ZPXMj?= =?us-ascii?Q?azq2WR6hmBqCGuXiUcoMD7jDX10WwLK6/JM9NdrhGQ23/NoCGkvtac6e8Ljd?= =?us-ascii?Q?KayTmQlyQIhw0GhrErIA9KwwR2LlEoHdTDxA0Cgu0Bm4Iat5sHZ0ksCdbFWN?= =?us-ascii?Q?jqjeaQ0TzW2xNVqtxjwGXgnR2AbdWnCba6o0qg0tNnwAYij8FEf0uhBvmHiH?= =?us-ascii?Q?995O1AfiGnNWdMGEjPOfhzoWSy/e8+UYk61HhmQD6MV9J4QxKfIX6pI5pnt1?= =?us-ascii?Q?a96QMbsdofzUr8NoHOVOiRlGxLUChcC8xSJaH+ayRHyUqUonip9i9n+JTA5W?= =?us-ascii?Q?GejDItObHzI7FuEI2dnA/K9a8tweXfF3q9jgYwf/UNSWuLEA3TmUufmNZG8C?= =?us-ascii?Q?pHQA/q69mZTMtVTw4r1mz6ytNEp5jhRDeovKMfMb3Tl+Eg5FkFm1dgqCTEam?= =?us-ascii?Q?PyrXkolpY7vfP7QLTQqth1LEZdZa8FwX4k2uiwuosN7bclIu1Oz2eOye/peB?= =?us-ascii?Q?rdFonAI5wnypTeaZRbnzuTDJnoBXgc/jvd45S0MQYCbWStbSuRk7MpvE/pNo?= =?us-ascii?Q?kirTTcbxohHzdTqQUIrEtu2JHBDljK7NDGRi62wCMYnLJggDPkLukQj+0sRK?= =?us-ascii?Q?1oi0jRm//whiGb9BQv83MkiSzO/Xixeo3NQ4tT76gfeJzvQlXp2LI+h9YrZi?= =?us-ascii?Q?y3yKQS/Alp5tm7m3yBOSKZav9cSs/Df83Y6rH8+X8ZxQTN9lxDri/HgxR+rR?= =?us-ascii?Q?4Wf8FlFaa2VVP6KJ83U4hxVcfqZIKK8mS0ocHNmHl8admfVTEUMmoLdYFu7N?= =?us-ascii?Q?BCGxWBBhAhJprXE7GHGw7Wv75t4Pp7bMU7o0OEr1rCIatXVCd5UwNRpyPZa3?= =?us-ascii?Q?4V6RA9QcbDQ/28bRi0NhwmZDa6eMVKhATlfHTHyvVyZUo6e5GGbu1JkKNZnw?= =?us-ascii?Q?C1BsgpvWPyhE2w5f8dAxgAgLgXcr1jgGYAMPAumGgg0gnUQBgfrJ6tQRemy6?= =?us-ascii?Q?GNKy39tAfUoLmabSiaVVKJgOYOrytopBIVP1CWULtG1kyeBRzZbfPKFjSA/0?= =?us-ascii?Q?F1ZiPfk3u3nwoWifq8aeWSBrrVVtSDhUDCoCnHT590I2Q5Q7ZztLcLmTSGNT?= =?us-ascii?Q?USHOKuX3jA3/IFYU92WYs4W7wm1bJrLDaNeyrfD+peRzjxp219X0kSLhvffN?= =?us-ascii?Q?/EDphVeJa5c7girAKAu3PKiUrZym17Q08RbJR3kMPdY+RjzIL4ZmKFH7/gWe?= =?us-ascii?Q?RjrZgqUhppp3U/TGhk=3D?= X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 6:15t9Vr/OW90QeYeuGdb+/lA2COctAilzrdSuPJggX2wu3VESaH28tOtn2dY0XdTJUtD2RnHG3OnzaMrEOTivqNBtrr9ZNJBySuJYUCNOzWthtY9xBp7nMBuK9cCzU3lia+AgnoDpzlNMED3cI2CYmEX/NL8rgdE9jW3CK4QpexVWKFp8NLU/J/gB/1pbVLMkVMZhXr+wXsw9Yw0sAiZQAIw0YmXcv7FAirK/qqaPrhmGPyQcvZN4bb5FPVfBMojlS6WsD5LeXgZnoBnBuz5a46Rl0vTFBhnOiWSGQllC690/+QG4LdQPhFWpu4ZiGxF+h3esTUWaTKPalr9lBM2Xg0arHZlx4fYj1plQCndHvWA=; 5:TJnbNsXbMVp9daAWwop87n45QZASc72GcW3sR7abPkFNV5EY+/plHULR7BKEFloeAmXlfsWLKFWqOSAa9iuacYTyvOHbeYxKglxAZxmpy+hwW4z/LEHjJupwN7pr2evliyaFqJ781aq3Iw858BuIy5O06CnJiidLhRPUCJQoyVw=; 24:z8m4CFDDkrfMuriI3T3lKG7bdB8uNu6/DXO/Dsomnkd/Lqmb0Od73mRyW3WoAT7JUnS/aiR2Dtox6nCkABeRcD/kKZgc+aInOjGRlVsBCoU=; 7:ZoasvgcIc/oTQd0LwNEZ1NTHUemzvQLyJfc4N7zoIPDG4gQ5ElEzX7df4x0Ag/kn7nWDbeTOaGS9y1eJqMUTjwF0KKl9BhuAUr2wzshmkrc2G5PdHSzpNRCXYAADbzO1zY9fxn93Xs3RB6x9v5raNBOci9q2ku9uTEMvxsignHtX07uAMKANEBlECtFtlZDedq++hEVv4EDTrDqg8WuGrPZtMn3DYnGxBx1cDO6bJYQvn6NwXZkEma7wNgqPs4e7 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 10:02:01.1011 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 681737b5-2f42-4bc7-e37d-08d536471320 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR04MB0695 Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5188) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 10:02:13 -0000 agreed. > On 28 Nov 2017, at 8:17 pm, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5188 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 7.1 >=20 > Original Text > ------------- > Validation of a certificate's resource extension in the context of a > certification path (see Section 7.2 entails that for every adjacent >=20 >=20 > Corrected Text > -------------- > Validation of a certificate's resource extension in the context of a > certification path (see Section 7.2) entails that for every adjacent >=20 >=20 > Notes > ----- > The closing parenthesis is missing. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Tue Nov 28 02:30:25 2017 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 6BE3C126B6E for ; Tue, 28 Nov 2017 02:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 t9FpgClg4LBL for ; Tue, 28 Nov 2017 02:30:20 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 41494124BE8 for ; Tue, 28 Nov 2017 02:30:20 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id r37so34874086qtj.12 for ; Tue, 28 Nov 2017 02:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XUGhUhqJFp4RqD7uEt6QzIO8WahlJPTWJodom7Wmg40=; b=leYLpS1k7GKR9bD2ChVva4qP7YVS8SFhxbUvm9fokLK+U70fq0O/owhjkbGfURJYPI xyWGbLALUGAM3nAi2AVcglPBr0GLo45Pm34DbmeGW05KT2z7Lsz9Lf+se+DB9JDMpKaO qT4JLW7sfO6yO5Z0e1O1RMnLne12k77lIwmqDir52I1y64NnH2NBu0nTtBb9G32tEEHF A37mvMs/ZEIcYcKfI/0ZdHCkJBMyUT/MgmXSp23fCzPidpUd3nrQ6ISfMGwXo2LEF+Os /jMPav/cfokJHeowuxMcQtql2v0UKZHhBHdswWhH0DbhBihcOozhm9yK9XOGaG9r+Xov 13hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XUGhUhqJFp4RqD7uEt6QzIO8WahlJPTWJodom7Wmg40=; b=Jgd2Ie+49rMyM8HAsTyoRX2+XAzNye747OD5DWfl8aSclKW8l324h7X1cDs6O8Em56 LTNNyN/6agr0l+WJW0zkYGTpA0ifI6xP0AAzFathXRmSZsS/Zm3HQ+Ywe9SFrMNGW0rK XFsXrMLHQX3Gygd+WJuB0G/mRXj1RNQmrQMuMMtATj7xqiQNLJEx4mAhKHYquDspEemk 50ff3AT7WtOq79uxNwZeQpdpnY+UjlNkLWm3cLD0+kkC1O9y5frRF5H++TKOvpYAKC+r 84o07oQBBv/Fybg5YQ+HSGihWwLw1bK78BMDvcEbxiTqwENTqFh8Lw9Pa0hgs13UIc/9 5CZA== X-Gm-Message-State: AJaThX7sbykrNGWVf7ng6iDMiohmIp/TD8pnE2TolcaVarPsS+loQZ+2 Iiw5NDo+VNpVexvnWYAEcwxnBTyoaU6kuPyOEeU= X-Google-Smtp-Source: AGs4zMazxDYddze9l6K/8qekrVNbFKLZZ3HKPWLLvb+IIMpYH28i0tHCHgsrkJB7UmQnLEWbsn1MPP0A/U2gsHnb8Pc= X-Received: by 10.200.45.89 with SMTP id o25mr60180306qta.227.1511865019433; Tue, 28 Nov 2017 02:30:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.61.98 with HTTP; Tue, 28 Nov 2017 02:30:19 -0800 (PST) In-Reply-To: <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> References: <20171128090411.26C0DB80C87@rfc-editor.org> <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> From: Nikolai Malykh Date: Tue, 28 Nov 2017 13:30:19 +0300 Message-ID: To: Geoff Huston Cc: RFC Errata System , George Michaelson , robertl@apnic.net, Alia Atlas , db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com, sidr@ietf.org Content-Type: multipart/alternative; boundary="001a113e319a6e8739055f088183" Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 10:30:22 -0000 --001a113e319a6e8739055f088183 Content-Type: text/plain; charset="UTF-8" May but not must. What about certificate that contain IP address set only OR AS number set only (not both)? 2017-11-28 13:01 GMT+03:00 Geoff Huston : > Reject - in the context of resource certificates the resources may contain > both IP addresses _AND_ AS numbers. > > > > > On 28 Nov 2017, at 8:04 pm, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC6487, > > "A Profile for X.509 PKIX Resource Certificates". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5187 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Nikolai Malykh > > > > Section: 7.1 > > > > Original Text > > ------------- > > encompass > > Given two IP address and AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range element > > within the set X. > > > > > > Corrected Text > > -------------- > > encompass > > Given two IP address or two AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range element > > within the set X. > > > > > > Notes > > ----- > > > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6487 (draft-ietf-sidr-res-certs-22) > > -------------------------------------- > > Title : A Profile for X.509 PKIX Resource Certificates > > Publication Date : February 2012 > > Author(s) : G. Huston, G. Michaelson, R. Loomans > > Category : PROPOSED STANDARD > > Source : Secure Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > --001a113e319a6e8739055f088183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
May but not must.
What about certificate tha= t contain IP address set only OR AS number set only (not both)?

2017-11-28 13:01 GM= T+03:00 Geoff Huston <gih@apnic.net>:
Reject - in the context of resource certificates the resources may = contain
both IP addresses _AND_ AS numbers.



> On 28 Nov 2017, at 8:04 pm, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5187
>
> --------------------------------------
> Type: Editorial
> Reported by: Nikolai Malykh <n= malykh@gmail.com>
>
> Section: 7.1
>
> Original Text
> -------------
>=C2=A0 =C2=A0 =C2=A0 encompass
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Given two IP address and AS number se= ts, X and Y, X
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"encompasses" Y if, for eve= ry contiguous range of IP addresses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or AS numbers elements in set Y, the = range element is either
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"more specific" than or &qu= ot;equal" to a contiguous range element
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0within the set X.
>
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0 =C2=A0 encompass
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Given two IP address or two AS number= sets, X and Y, X
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"encompasses" Y if, for eve= ry contiguous range of IP addresses
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or AS numbers elements in set Y, the = range element is either
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"more specific" than or &qu= ot;equal" to a contiguous range element
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0within the set X.
>
>
> Notes
> -----
>
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Profil= e for X.509 PKIX Resource Certificates
> Publication Date=C2=A0 =C2=A0 : February 2012
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: G. Huston, G. Mich= aelson, R. Loomans
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secure Inter-= Domain Routing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing<= br> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--001a113e319a6e8739055f088183-- From nobody Tue Nov 28 04:17:45 2017 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 314D0127078 for ; Tue, 28 Nov 2017 04:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 WWuAr8MLoFqt for ; Tue, 28 Nov 2017 04:17:43 -0800 (PST) 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 16D89126B71 for ; Tue, 28 Nov 2017 04:17:43 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eJepV-0004Si-7I; Tue, 28 Nov 2017 12:17:37 +0000 Date: Tue, 28 Nov 2017 21:17:34 +0900 Message-ID: From: Randy Bush To: Nikolai Malykh Cc: Geoff Huston , db3546@att.com, sidr@ietf.org, morrowc@ops-netman.net, robertl@apnic.net, George Michaelson , RFC Errata System In-Reply-To: References: <20171128090411.26C0DB80C87@rfc-editor.org> <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 12:17:44 -0000 > What about certificate that contain IP address set only OR AS number set > only (not both)? s/and/or/ seems formally correct, albeit a bit nitty >>> Original Text >>> ------------- >>> encompass >>> Given two IP address and AS number sets, X and Y, X >>> "encompasses" Y if, for every contiguous range of IP addresses >>> or AS numbers elements in set Y, the range element is either >>> "more specific" than or "equal" to a contiguous range element >>> within the set X. >>> >>> >>> Corrected Text >>> -------------- >>> encompass >>> Given two IP address or two AS number sets, X and Y, X >>> "encompasses" Y if, for every contiguous range of IP addresses >>> or AS numbers elements in set Y, the range element is either >>> "more specific" than or "equal" to a contiguous range element >>> within the set X. From nobody Tue Nov 28 05:53:11 2017 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 680DB124205; Tue, 28 Nov 2017 05:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 uEiho4OboJ6T; Tue, 28 Nov 2017 05:53:09 -0800 (PST) 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 575A61200E5; Tue, 28 Nov 2017 05:53:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 042CDB81364; Tue, 28 Nov 2017 05:52:59 -0800 (PST) To: nmalykh@gmail.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128135259.042CDB81364@rfc-editor.org> Date: Tue, 28 Nov 2017 05:52:59 -0800 (PST) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC6487 (5188) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 13:53:10 -0000 The following errata report has been held for document update for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5188 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-11-28 Held by: Alvaro Retana (IESG) Section: 7.1 Original Text ------------- Validation of a certificate's resource extension in the context of a certification path (see Section 7.2 entails that for every adjacent Corrected Text -------------- Validation of a certificate's resource extension in the context of a certification path (see Section 7.2) entails that for every adjacent Notes ----- The closing parenthesis is missing. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 06:19:50 2017 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 6047C124234 for ; Tue, 28 Nov 2017 06:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 m0R0k1fQHTmh for ; Tue, 28 Nov 2017 06:19:47 -0800 (PST) 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 2DEC8120726 for ; Tue, 28 Nov 2017 06:19:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C689BB816F2; Tue, 28 Nov 2017 06:19:36 -0800 (PST) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128141936.C689BB816F2@rfc-editor.org> Date: Tue, 28 Nov 2017 06:19:36 -0800 (PST) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC6487 (5190) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 14:19:48 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5190 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 8 Original Text ------------- 3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> (A string of 20 ASCII HEX digits would have 80-bits of entropy) Corrected Text -------------- 3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1" (A string of 20 ASCII HEX digits would have 80-bits of entropy) Notes ----- Typo Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 06:28:34 2017 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 3133C12711E for ; Tue, 28 Nov 2017 06:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 hpiX13YEnC0O for ; Tue, 28 Nov 2017 06:28:30 -0800 (PST) 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 A047C12714F for ; Tue, 28 Nov 2017 06:28:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 41FB9B8174E; Tue, 28 Nov 2017 06:28:20 -0800 (PST) To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171128142820.41FB9B8174E@rfc-editor.org> Date: Tue, 28 Nov 2017 06:28:20 -0800 (PST) Archived-At: Subject: [sidr] [Editorial Errata Reported] RFC6487 (5191) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 14:28:33 -0000 The following errata report has been submitted for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5191 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 8 Original Text ------------- (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc. Corrected Text -------------- (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc). Notes ----- The closing parenthesis is missing. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Nov 28 07:07:02 2017 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 F406E124D68 for ; Tue, 28 Nov 2017 07:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GRctpnCc3E-x for ; Tue, 28 Nov 2017 07:06:54 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 16C2C1200B9 for ; Tue, 28 Nov 2017 07:06:54 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id h2so75189uae.12 for ; Tue, 28 Nov 2017 07:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3WlYjJYqQmrWivez+ohSpkNIZ5ihAsgH+B0Op9KuSXU=; b=MSiVZK60x+xKM6mPJn4QLNs7XLW0UqGSBeoZIS5Vv88LYzaiTbwqQi6NhR3fLvjMg+ Yvd9WykDFmeBO2iL1vtGOR9aVnk1viUMHXH/UTTwHK6q0z+iE7IdaCJKTkdrDev1dJCF fMUcalXKMPKmf8b+sxNss1OsL3GtpgRwMSEiqOyMV7o0HhIoXYwnqEAHUWrZCB++lenQ dzKqFnNQhSZqXnMKnbvkdjpe0y7r7eK4JRs+Tb/uSSk0v8t1wPbxoYvvVLGD4FkLzXFL GJyR5Xk6VlkiiP991hycD+g5OSKmV3D+clgz+UI8M34eV1cuOayJWFiHLxBO4SLtm7Mt Lgvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3WlYjJYqQmrWivez+ohSpkNIZ5ihAsgH+B0Op9KuSXU=; b=IhIA/HG0BsuEY+GAGPiOi+C81jHjWnLJEt46hb8WJ60WOvNn7vG0UUfdYV70zuhMAz U4Zt8c9Fxob15LN9Uyrb+aplsOGD1CgdG8PdrOpvXAB59DZeTD0ybfWIojPkcTkI27/t ustxgUCQfyVjAVl/oBMy8Qdgc1qFQtHJFBTjGeznX5dGfJwP/jZHlxtPlAzsLeR5O3s4 1jnM1bHp1747YVGK7at1oJuJHNKy/i5vfjvP2aHAER0UsbD68mzZ/BTqubD322MIHY0t raoKkAbkdNOUH3+XGpWTX+QscZO5KHH4UxjqVrOVEssw8/Jd57I0i9Q2he9GL6P2KCWZ gNGQ== X-Gm-Message-State: AJaThX7y/I+jSVFjaVx0K1+8OhOMdZWijypFQmut/F4kbMplG6pxnAh2 XU21CZByX19pOjwMgQd3HPTWEehpzPjnbLjqbbM= X-Google-Smtp-Source: AGs4zMYcMCtsTOlrzXU1utr15z6ePgmDog3v8s6wU3oiTx/0L/GXLmlK+enVExynXcZMpoSwuJHguGecf+p+R7M0Jos= X-Received: by 10.176.2.116 with SMTP id 107mr17461818uas.8.1511881612994; Tue, 28 Nov 2017 07:06:52 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.176.80.139 with HTTP; Tue, 28 Nov 2017 07:06:52 -0800 (PST) In-Reply-To: References: <20171128091723.92DE6B80D4C@rfc-editor.org> From: Christopher Morrow Date: Tue, 28 Nov 2017 10:06:52 -0500 X-Google-Sender-Auth: pZ0CVQ31eD9yseVCG3fBuoVjAgs Message-ID: To: Geoff Huston Cc: RFC Errata System , nmalykh@gmail.com, db3546@att.com, sidr@ietf.org, Chris Morrow , robertl@apnic.net, George Michaelson Content-Type: multipart/alternative; boundary="001a113e45d47c2fa2055f0c5e5f" Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5188) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:07:01 -0000 --001a113e45d47c2fa2055f0c5e5f Content-Type: text/plain; charset="UTF-8" sure! On Tue, Nov 28, 2017 at 5:02 AM, Geoff Huston wrote: > agreed. > > > On 28 Nov 2017, at 8:17 pm, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC6487, > > "A Profile for X.509 PKIX Resource Certificates". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5188 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Nikolai Malykh > > > > Section: 7.1 > > > > Original Text > > ------------- > > Validation of a certificate's resource extension in the context of a > > certification path (see Section 7.2 entails that for every adjacent > > > > > > Corrected Text > > -------------- > > Validation of a certificate's resource extension in the context of a > > certification path (see Section 7.2) entails that for every adjacent > > > > > > Notes > > ----- > > The closing parenthesis is missing. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6487 (draft-ietf-sidr-res-certs-22) > > -------------------------------------- > > Title : A Profile for X.509 PKIX Resource Certificates > > Publication Date : February 2012 > > Author(s) : G. Huston, G. Michaelson, R. Loomans > > Category : PROPOSED STANDARD > > Source : Secure Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a113e45d47c2fa2055f0c5e5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
sure!

On Tue, Nov 28, 2017 at 5:02 AM, Geoff Huston = <gih@apnic.net>= ; wrote:
agreed.

> On 28 Nov 2017, at 8:17 pm, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5188
>
> --------------------------------------
> Type: Editorial
> Reported by: Nikolai Malykh <n= malykh@gmail.com>
>
> Section: 7.1
>
> Original Text
> -------------
>=C2=A0 =C2=A0Validation of a certificate's resource extension in th= e context of a
>=C2=A0 =C2=A0certification path (see Section 7.2 entails that for every= adjacent
>
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0Validation of a certificate's resource extension in th= e context of a
>=C2=A0 =C2=A0certification path (see Section 7.2) entails that for ever= y adjacent
>
>
> Notes
> -----
> The closing parenthesis is missing.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Profil= e for X.509 PKIX Resource Certificates
> Publication Date=C2=A0 =C2=A0 : February 2012
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: G. Huston, G. Mich= aelson, R. Loomans
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secure Inter-= Domain Routing
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing<= br> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

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

--001a113e45d47c2fa2055f0c5e5f-- From nobody Tue Nov 28 07:08:15 2017 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 0AC9F1200B9; Tue, 28 Nov 2017 07:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HRduoA-CNmdd; Tue, 28 Nov 2017 07:08:02 -0800 (PST) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (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 5951B1243FE; Tue, 28 Nov 2017 07:08:02 -0800 (PST) Received: by mail-vk0-x243.google.com with SMTP id x140so213305vke.4; Tue, 28 Nov 2017 07:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jVxdiCEMCVQRiWp6MwOoRo4LaAdM+HmiuWNe+tbkcIE=; b=O/EsPoBIuuYZ+X9RKP0pa8Vzpeho2Vfr1zUhkIzjpePmpvgq4KRC03IY53cSWr9wCv kHb73Ow75PS+VoiAuFg1Rn+amVXf0T90R6Ab0lnlhA1dHSnlWEW5/Xnugju+jgsvOxeW PQ1Ze1ILoZ/OEsy/fPz1wIpcBJMNNBgNwGIV+UBi83pX56o7RT9O626qvAa+0lvmDECQ 6mM93BOElfnPTwy9vzaPuPkJYJs8xWqLW1Tn2p5dzd6HEscM8DJKuSG7YMxuPAoRTaMN Lw4DSRq8rvCbVydtOF5dT3JYcAif5UTZXaIDJFm3Vx6fqQgcFIDaGZaLOCxDjM1Hs3rn vWzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jVxdiCEMCVQRiWp6MwOoRo4LaAdM+HmiuWNe+tbkcIE=; b=pdCUZ/pZOMqb2YvHJa1GdprcwbDk6fezBTjFNp9NmjxJMLCU24YEEVpELuDrHkb3tD hY2XmqBqiH0BfKeJOatcq3ZTHPd2bj7RWCFEsOTGuyZt2L29TpqB2uK33OXJ+3Ns9Vr9 KyuL5mAdIwkkYSJBaOMPKykYhwPFt8z3O0nhJ6+Rokwfl8MJ4dxRIRT++2ibrwLLwxBp 9e1YLoRxunl3U5PfWEGVQDe3Eqk43S/QVvIvms3MuB/Oj8tn2rs6TB5YA0yK91b4L9ej BNx2U+UfAz8pF66IketNsTUTOmu7vPdVihmoby6QG7AJ69VFhYqqYbK0+kwkg0f4tZjZ 7yWQ== X-Gm-Message-State: AJaThX6GIFQWwilkyNLTi39A42l610WtdTafElWYhfauDNMOjv4nZ6kU 71CRcFGRBlVl0mMns57Fm2KmAHQaXx6VbR82rBg= X-Google-Smtp-Source: AGs4zMayuIK+qy7Bp60KDT/pg9I+2Fvz96qZXcfspW3MY6rAMlUPnenmSiDpm2TG9/6ZIxvrWYSG+m4BPfgSn3LIDgo= X-Received: by 10.31.170.134 with SMTP id t128mr4090703vke.172.1511881681319; Tue, 28 Nov 2017 07:08:01 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.176.80.139 with HTTP; Tue, 28 Nov 2017 07:08:00 -0800 (PST) In-Reply-To: <20171128135259.042CDB81364@rfc-editor.org> References: <20171128135259.042CDB81364@rfc-editor.org> From: Christopher Morrow Date: Tue, 28 Nov 2017 10:08:00 -0500 X-Google-Sender-Auth: mGGzw8D9PwdJmOUB5NEUdvz5Lrc Message-ID: To: RFC Errata System Cc: nmalykh@gmail.com, Geoff Huston , George Michaelson , robertl@apnic.net, sidr@ietf.org, IESG IESG Content-Type: multipart/alternative; boundary="001a1142d9548ebdfc055f0c6294" Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC6487 (5188) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:08:09 -0000 --001a1142d9548ebdfc055f0c6294 Content-Type: text/plain; charset="UTF-8" this is reported 2x? On Tue, Nov 28, 2017 at 8:52 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been held for document update > for RFC6487, "A Profile for X.509 PKIX Resource Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5188 > > -------------------------------------- > Status: Held for Document Update > Type: Editorial > > Reported by: Nikolai Malykh > Date Reported: 2017-11-28 > Held by: Alvaro Retana (IESG) > > Section: 7.1 > > Original Text > ------------- > Validation of a certificate's resource extension in the context of a > certification path (see Section 7.2 entails that for every adjacent > > > Corrected Text > -------------- > Validation of a certificate's resource extension in the context of a > certification path (see Section 7.2) entails that for every adjacent > > > Notes > ----- > The closing parenthesis is missing. > > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a1142d9548ebdfc055f0c6294 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this is reported 2x?

<= div class=3D"gmail_quote">On Tue, Nov 28, 2017 at 8:52 AM, RFC Errata Syste= m <rfc-editor@rfc-editor.org> wrote:
The following errata report has been held for document u= pdate
for RFC6487, "A Profile for X.509 PKIX Resource Certificates".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5188

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Nikolai Malykh <nmalyk= h@gmail.com>
Date Reported: 2017-11-28
Held by: Alvaro Retana (IESG)

Section: 7.1

Original Text
-------------
=C2=A0 =C2=A0Validation of a certificate's resource extension in the co= ntext of a
=C2=A0 =C2=A0certification path (see Section 7.2 entails that for every adj= acent


Corrected Text
--------------
=C2=A0 =C2=A0Validation of a certificate's resource extension in the co= ntext of a
=C2=A0 =C2=A0certification path (see Section 7.2) entails that for every ad= jacent


Notes
-----
The closing parenthesis is missing.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Profile for= X.509 PKIX Resource Certificates
Publication Date=C2=A0 =C2=A0 : February 2012
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: G. Huston, G. Michaelso= n, R. Loomans
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secure Inter-Domai= n Routing
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

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

--001a1142d9548ebdfc055f0c6294-- From nobody Tue Nov 28 07:08:42 2017 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 6BB0D1243FE for ; Tue, 28 Nov 2017 07:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0MgSKi3LSxN1 for ; Tue, 28 Nov 2017 07:08:39 -0800 (PST) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (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 863C81200B9 for ; Tue, 28 Nov 2017 07:08:39 -0800 (PST) Received: by mail-vk0-x243.google.com with SMTP id u84so197967vke.10 for ; Tue, 28 Nov 2017 07:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OStN32XWqXuW/+jXmsKrlaFLbVe2OR8iZNwvM+va3XM=; b=CfO4mRwIQy/ElILUvOM2JKzNJYMDeidcQenMo9NHDJETMxf9N4dUNVnVwSeciSjosk XnxK8CoGtzyxZTQ+uYjeqvqWhnfHJuJmNvZMQmyzLjy9vBNtbDD2tWSXLZ5PQOg8cRHA J+M/HdMAQAkNdp9F19Rm2CRZBeIww2KPYmWT8HEl2GGQptlMQqH+SRXreku4apsZD2ED kFSbiZ6wkV9EFLTciPONheWu6tj7b2JOcpBt1n7LPFYKkBsrLg/j7syYybreAL1rVeL0 Y0opyBo75R6Y1lu2OjLYk8A3ALUUW7KAZFEMMmjrg1rWrK4KX6no/LUC7wI0iE+5nKJJ +3aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OStN32XWqXuW/+jXmsKrlaFLbVe2OR8iZNwvM+va3XM=; b=BPEuXKia08KnzXokzkZKt3o5OI/zmvBg6BT8b3mFzE0HjJ+WoU3ug8m0O0IIjY1Ozx iVJF5Hy5DKbWsLDRQVUCyuyettkA4X3jpBaSGUq9dMlym9opTH9Pbobfg4jOBp0PxBAE //D7ROWL9udSrnpTB5/MWw3TV8XKXj0Il1V3gTwSrUYsNCrWTS51zGAWu726YabWot97 HJnsGbslB97dO4l+itZ4ITEbUT4AlUf8eFX449oXGNqrDKPD0rvs+fpbnt18LNABGuhh ymxvYaPXxQ8NOOe2V7u+Qxh+Sv4TYPYek7k3Jnz1zCPYv68To5VS9P5s5QKtfd0VxZzi 6MDw== X-Gm-Message-State: AJaThX4pTIUIPWfsFHBm7mXjF88zF5F4F7UQlSFnosq7/Pd6mvX+TGug GC0+uSg8DCWOQokVdZiLwDqqEQTAWm3uktRjx64= X-Google-Smtp-Source: AGs4zMZMAVou/yx4YKTfhb0F7aaAaThbXlR+r4WXux6fNLbwbTKWDXRTx5BHmkMd2OVo1Hy/1BM2wanLNhAUK+KFEOs= X-Received: by 10.31.74.194 with SMTP id x185mr24370033vka.104.1511881718509; Tue, 28 Nov 2017 07:08:38 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.176.80.139 with HTTP; Tue, 28 Nov 2017 07:08:38 -0800 (PST) In-Reply-To: <20171128141936.C689BB816F2@rfc-editor.org> References: <20171128141936.C689BB816F2@rfc-editor.org> From: Christopher Morrow Date: Tue, 28 Nov 2017 10:08:38 -0500 X-Google-Sender-Auth: D2Lryioj6ozTJXLkzU-ziT-FZRs Message-ID: To: RFC Errata System Cc: Geoff Huston , George Michaelson , robertl@apnic.net, Alia Atlas , db3546@att.com, aretana.ietf@gmail.com, Chris Morrow , Sandy Murphy , nmalykh@gmail.com, sidr@ietf.org Content-Type: multipart/alternative; boundary="001a114db744c63743055f0c64ad" Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5190) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:08:41 -0000 --001a114db744c63743055f0c64ad Content-Type: text/plain; charset="UTF-8" spare > seems spare... On Tue, Nov 28, 2017 at 9:19 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5190 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > Section: 8 > > Original Text > ------------- > 3) A randomly generated ASCII HEX encoded string of length 20 > or greater: > example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> > (A string of 20 ASCII HEX digits would have 80-bits of > entropy) > > > Corrected Text > -------------- > 3) A randomly generated ASCII HEX encoded string of length 20 > or greater: > example: cn="0f8fcc28e3be4869bc5f8fa114db05e1" > (A string of 20 ASCII HEX digits would have 80-bits of > entropy) > > > Notes > ----- > Typo > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --001a114db744c63743055f0c64ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
spare > seems spare...
=
On Tue, Nov 28, 2017 at 9:19 AM, RFC Errata = System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for = RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5190

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalyk= h@gmail.com>

Section: 8

Original Text
-------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) A randomly generated ASCII HEX encoded= string of length 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or greater:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 example: cn=3D"0f8fcc28= e3be4869bc5f8fa114db05e1">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (A string of 20 ASCII HEX digits = would have 80-bits of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entropy)


Corrected Text
--------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03) A randomly generated ASCII HEX encoded= string of length 20
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or greater:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 example: cn=3D"0f8fcc28= e3be4869bc5f8fa114db05e1"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (A string of 20 ASCII HEX digits = would have 80-bits of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 entropy)


Notes
-----
Typo

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Profile for= X.509 PKIX Resource Certificates
Publication Date=C2=A0 =C2=A0 : February 2012
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: G. Huston, G. Michaelso= n, R. Loomans
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secure Inter-Domai= n Routing
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

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

--001a114db744c63743055f0c64ad-- From nobody Tue Nov 28 07:10:03 2017 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 8DFA3124E15 for ; Tue, 28 Nov 2017 07:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fuAyCgaqtWZi for ; Tue, 28 Nov 2017 07:09:55 -0800 (PST) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 C3D6C1200B9 for ; Tue, 28 Nov 2017 07:09:54 -0800 (PST) Received: by mail-vk0-x241.google.com with SMTP id o70so207243vkc.9 for ; Tue, 28 Nov 2017 07:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=d+hS87512nURU62cJlyTBugcPAiLLrWOpGEClwg5nDU=; b=kGOEvpqypPsSKR7BUep9bigoSX/V1TuSmyX84OEc1iErZGlFM0uZ7ffFoeKEiCJCqO ywj1Ar7bJSF3w8SLbOn6l/qAqJqcKT8j2dz5DQRySmYb04rkxOAdEJ2VxsRvXdfwVLS/ zAfTp3N30Vb9ig3CRFyVH1UTEkdRLeYf4ObYgQhzVTfe5EPY5wteZPHedINFs0VO6g90 HCIMx+3RcqlfSxo/yEmZmDSztyCsoJxq4mDXtRgz4f8VIRYkrtHe+VZiY4aE/8dLPMLX YlCQU6GHxhyKQANHflDw09eStOAwTjHlrFWUtpv8U1DPNHu+uxB387p9uWVmtTq/47x0 qjkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=d+hS87512nURU62cJlyTBugcPAiLLrWOpGEClwg5nDU=; b=ITq5ybbKqEE1L/I0RjjLoZ0LdMAd6LS+1g32qIY2dW6pCm1JdvdMlM5cTmfsNRkupH Kv7GgtHMni+XIQQyb0XA+My6C1HThFBFfWxOFH+v9hY+zzMaE6bIlWbW2r3t7rawHurR weh9fmDC+zj7FSR1Szb323C9WsZ2gHtr638OPa1BawafiTAPs7vlHmN0+YvYYNh1G7w1 GxRBbr5qw0f02oai5nUGQnAY52dSlbM47jsnddNvPxw5FZlh+CtgBPTktR2NUiGhgVL1 DBymMhwbh7IXlBymJNXHGJVgKVJSraZF5LgOfmJVEFT4FCunm3kqCr9wyK0EODfgrWCf Z35w== X-Gm-Message-State: AJaThX5XTTLZBDqJIebg+Woj5TU5qFg+KDt6L+0kP77Fzx45vkSie9KV JC2sCjzftJFdSJp18prNhpF/WHT7TGfTkOujDgM= X-Google-Smtp-Source: AGs4zMZVqnbbKYrItiEh4ERB5DIA/a9APNqkIcOhjplvSaFlyPyXmogjITv2O5aSoaF3MPv5mAnmU90KjYIXnsjCP0A= X-Received: by 10.31.218.194 with SMTP id r185mr31779065vkg.110.1511881793753; Tue, 28 Nov 2017 07:09:53 -0800 (PST) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.176.80.139 with HTTP; Tue, 28 Nov 2017 07:09:53 -0800 (PST) In-Reply-To: <20171128142820.41FB9B8174E@rfc-editor.org> References: <20171128142820.41FB9B8174E@rfc-editor.org> From: Christopher Morrow Date: Tue, 28 Nov 2017 10:09:53 -0500 X-Google-Sender-Auth: REuB4LjVg-SkEB3SCmR0LSe0fBc Message-ID: To: RFC Errata System Cc: Geoff Huston , George Michaelson , robertl@apnic.net, Alia Atlas , db3546@att.com, aretana.ietf@gmail.com, Chris Morrow , Sandy Murphy , nmalykh@gmail.com, sidr@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07b1ea4258e9055f0c6930" Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5191) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:10:01 -0000 --94eb2c07b1ea4258e9055f0c6930 Content-Type: text/plain; charset="UTF-8" seems legit. On Tue, Nov 28, 2017 at 9:28 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5191 > > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh > > Section: 8 > > Original Text > ------------- > (The issuing CA may wish to be able to extract the database > key or subscriber ID from the commonName. Since only the > issuing CA would need to be able to parse the commonName, > the database key and the source of entropy (e.g., a UUID) > could be separated in any way that the CA wants, as long as > it conforms to the rules for PrintableString. The separator > > > > > Huston, et al. Standards Track [Page 21] > > RFC 6487 Resource Certificate Profile February 2012 > > > could be a space character, parenthesis, hyphen, slash, > question mark, etc. > > > Corrected Text > -------------- > (The issuing CA may wish to be able to extract the database > key or subscriber ID from the commonName. Since only the > issuing CA would need to be able to parse the commonName, > the database key and the source of entropy (e.g., a UUID) > could be separated in any way that the CA wants, as long as > it conforms to the rules for PrintableString. The separator > > > > > Huston, et al. Standards Track [Page 21] > > RFC 6487 Resource Certificate Profile February 2012 > > > could be a space character, parenthesis, hyphen, slash, > question mark, etc). > > > Notes > ----- > The closing parenthesis is missing. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --94eb2c07b1ea4258e9055f0c6930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
seems legit.

On Tue, Nov 28, 2017 at 9:28 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitted for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5191

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalyk= h@gmail.com>

Section: 8

Original Text
-------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (The issuing CA may wish to be ab= le to extract the database
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key or subscriber ID from the com= monName.=C2=A0 Since only the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 issuing CA would need to be able = to parse the commonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the database key and the source o= f entropy (e.g., a UUID)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be separated in any way tha= t the CA wants, as long as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it conforms to the rules for Prin= tableString.=C2=A0 The separator




Huston, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Standa= rds Track=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 21]

RFC 6487=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Certifica= te Profile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 2012


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be a space character, paren= thesis, hyphen, slash,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question mark, etc.


Corrected Text
--------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (The issuing CA may wish to be ab= le to extract the database
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key or subscriber ID from the com= monName.=C2=A0 Since only the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 issuing CA would need to be able = to parse the commonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the database key and the source o= f entropy (e.g., a UUID)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be separated in any way tha= t the CA wants, as long as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it conforms to the rules for Prin= tableString.=C2=A0 The separator




Huston, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Standa= rds Track=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[Page 21]

RFC 6487=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Resource Certifica= te Profile=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0February 2012


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be a space character, paren= thesis, hyphen, slash,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 question mark, etc).


Notes
-----
The closing parenthesis is missing.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A Profile for= X.509 PKIX Resource Certificates
Publication Date=C2=A0 =C2=A0 : February 2012
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: G. Huston, G. Michaelso= n, R. Loomans
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secure Inter-Domai= n Routing
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

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

--94eb2c07b1ea4258e9055f0c6930-- From nobody Tue Nov 28 10:48:21 2017 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 9F405128B37 for ; Tue, 28 Nov 2017 10:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.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 Tw1TtO_lXmpy for ; Tue, 28 Nov 2017 10:48:16 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0055.outbound.protection.outlook.com [104.47.92.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFC1126557 for ; Tue, 28 Nov 2017 10:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lw4yzAHeUVgsCgM9QflIu4OpQWxWxJhKesrRp6Ls9oM=; b=IipRoQCbVx2ft8rFXImDBCN8rPR1L9a2yTPtTaVf2JGhYFPEaoTPxth/R8ngXG+muH5xGOzI7hH5aiVcBFfpKwXinjX2AVOz4D2UHsP2h3CHkeiRYwuzMKdVvfreu63r0YizKkYFGNNyKEm3KD6W4Et6EuMx4mEcSiDiLOasK44= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from dhcp202.potaroo.net (203.16.208.142) by TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 18:48:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Geoff Huston In-Reply-To: Date: Wed, 29 Nov 2017 05:47:37 +1100 Cc: RFC Errata System , George Michaelson , robertl@apnic.net, Alia Atlas , db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <147D5A96-CCBE-422B-AA82-C12802256844@apnic.net> References: <20171128090411.26C0DB80C87@rfc-editor.org> <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> To: Nikolai Malykh X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [203.16.208.142] X-ClientProxiedBy: KL1P15301CA0021.APCP153.PROD.OUTLOOK.COM (10.170.161.31) To TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1668fcc-6482-47be-5005-08d5369092af X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 3:Z2BZEhiXaovc9eO5ZKqEx04ZYbM/Zc/lXLV4w9EJuI0ZFswKW1dblvonqbtzv5ffAKnuaHS3DMCqXwAWqu47K6OrBx9GKvK4mO6m0vOsURGtcbSUsKN/FRGkkrYJ+pxVeM53ENqO1IuY9V3V9VbIFykjwmBYa4JznWc4yuDwCr+KBay++ipKRvmFvKSPMEjfEoOuApm9ACzw3dkusM0V/tAwijXgxVT6vsqNOzyy0YXcpl7OSl26UpKG2y/Qd0S8; 25:GZQhZ1orvlfRAGLGxCRuSCO6O9nP8Ln785cYlLPyjfgNJpgJ0F6m4CxGi2Jzv427etGp6cghJ/9LouQ8aQzyucSeMxErzVmYWoqVm22iHW7K3InP/R5tCex1dKaOGInsYl1EkPvSr1hNJceoNSTPvSo3EpMdGT4y+F+yK9u9qZlTxTFckv9b65hZaksq7effZzyeXDbAFFBJFVE9d3F2NRdFet5ZAUgiNJUZ2cEXN6UonfldlG8qw16zSGIG38dQhsxU9Tg0w8rCPHeEfV/WfqpOAs31EIPXluFcMp/vb0krVGkcIZMo03nZMU+Php+4js+zedPdxcXA91JYfIX1IA==; 31:ulYjjLkkdaS+Uu+8aV/ShYKZWJntrBlXspSFHrE+pFxwDA0WpAtevqKBW4B3sFRQe6zw1Y7cS4NJOzISy4rCIjA0uOlN3cIlHESntkDdWVRMUZEXlDm8Gjg8E+rRuJzgzgBE8rZ8VV5/ljR9usq8Am437jd/acI8FiEa2sd5PCngH1G3/r1ooNji5XkxXLdzOuGBImiiMbcs6BBu99tVmcongUDeIYJuJ19rGPFU6I8= X-MS-TrafficTypeDiagnostic: TY1PR04MB0703: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231022)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:TY1PR04MB0703; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 4:ZvJdHJ133cK157c/Wp9BudOq2hI3/AuYIqFyOrVM0HYSBGkW9ZuSEFa8kDdMO2AoOG3miPRQA34fid+VZV9mcuUk/8uhPUjRrIhCBm4A7AbTCjopse4vJVeUIOgXp97D0O+LaV/F1tyHLUQTRePZdMCiaA11R7Igp++Jx+FjmG4d0tIezp7EIqTu+2iYQ016RZ1VXMTfLXZStMQltPrLY4GLAFcKCTg0J7PlvTwc7bxYDvrT+rpSJy14Z6rssOKNUtq8jVM8nBNeKcs0J/0A2TbylMrKFX6ogSIBuX+ovVdR5Ieuin3ZuARuLxd+aN0E X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(199003)(189002)(24454002)(377424004)(6116002)(50986999)(47776003)(23726003)(2906002)(66066001)(76176999)(966005)(50466002)(36756003)(25786009)(57306001)(101416001)(6512007)(508600001)(3846002)(105586002)(5660300001)(53936002)(6306002)(7736002)(16526018)(54906003)(305945005)(106356001)(33656002)(97736004)(1720100001)(53416004)(8746002)(4001150100001)(8676002)(81166006)(81156014)(6246003)(8936002)(52116002)(6506006)(1411001)(4326008)(189998001)(6916009)(2950100002)(50226002)(6486002)(86362001)(69596002)(39060400002)(229853002)(53546010)(68736007)(83716003)(6666003)(82746002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR04MB0703; H:dhcp202.potaroo.net; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; TY1PR04MB0703; 23:/iPhPZwf2qecSYCIDG+LT8gSrf6JSACXOx7+QygGv?= =?us-ascii?Q?1gvuSnNGQet1luYY/R5+VvdAWA/jO26tXLVpZyX9oO5ADBNCZuRHTc3P5ooT?= =?us-ascii?Q?oec9OnDJ0IbfXH5JH0tNQUVJHyoTBTTpy5QjY6RVLE5yPPHMP2+oq9hkTgpS?= =?us-ascii?Q?wLGXMy6epGbThQT5a7bl17foYi+1/1qfZTC3DjzdTRR/vVMS63UA/KejKGac?= =?us-ascii?Q?99aiLPCgHq/BlpzYG2PI1KO+1R2xvV4YzkgC3p5k6k7Ja0T5FFP6/rUKMjKQ?= =?us-ascii?Q?hjg9hdMhBFne1iIJdBxO98kLmsoOkSCMHCONk/k/QGkef2/GpuAWfjgeIq3E?= =?us-ascii?Q?N/in0D9EVbGJvb1qbqc6GRDySvIdJj5/spIEzSWRqcyP8TjD20vzApCqPg3S?= =?us-ascii?Q?8VvJy7+fIPXmlDvoBacKJfL5zNGoX98VqiRWVleWK8MGcg63AJp06OYoA7+l?= =?us-ascii?Q?mlT0H55CLD2a+GXDqWLDHy2ul4bnObQdDmaYxuxbuu9785QhQ/3vb1f6+x4n?= =?us-ascii?Q?FMCYyJRn8qnnhi8k9xyvS4sLkR1SiGzXhsolQIhB0ktfLU0X7RUiimoppj7v?= =?us-ascii?Q?USIMPVHcsf1zhZqkQ1nQxh2sJhkr6PucGm5r9eQrn0OWwRHYMWCCRKIHhOJQ?= =?us-ascii?Q?z4MXvsypT/MJNDGP7Qwg06CvnGHlagORcgL5Rt5ImLwSLEGQLGjUl4PLY0cA?= =?us-ascii?Q?fOcB8I+VowpMNYxpbOhOAeVo7ZdGI8XrUiInzz2+dUEW1/16zfSUHqZ05SdT?= =?us-ascii?Q?ysCGjFQpNjgON20i2e2Zv4g2HFO0jvQshIpPdX56NX6md6kE8dGNony3GdrW?= =?us-ascii?Q?hSG16Wb+JDvZGlq2LtDP0nTsoXnx4TeeisLO66NZ8pePfcmIjsgHrvBRfID6?= =?us-ascii?Q?7f7TGvrqaviZEs6iql2HaG6cdADjUteCJf8YEklMNKQc8uVdqHtXQZOd+V7R?= =?us-ascii?Q?7M1j+NfH6tAu7Kr01n5gaBPIP6KIiTnoNmhhHZtfwlj5pdwuL0AZuelRrKwm?= =?us-ascii?Q?Fx8ZwFcxdBeLAScPOevFWotxh4cnAkfuYJK5H8iacjzR1mkVnQUOORVeDkdC?= =?us-ascii?Q?U97mtsNEomnZS/54Drr90A487lA6ipae6RZMH9NGWbdsDO9zw2xyweLyorjH?= =?us-ascii?Q?gCmpLJuTM0fbHO3I+F2TSMwHFMDMWa+vDJltqUXMz8SiM7ueKgCrPyXcI1MJ?= =?us-ascii?Q?WIeQXM6vdgGeWHpvdS/lGbSvbAt1nbAdkrKnzXMHbUsMmSQsc1MbNailB5SY?= =?us-ascii?Q?qorVmOKyXWGqmsrDwXw0d8ZfpjeWxT524FB8zDvOygBgJzDEfvED4BXUaASt?= =?us-ascii?Q?2n6AhFis30IVoV9Ck3yI2+guYpiSQC28ZQ0DFM3VNgn9KBNHT9EpHENPOeYB?= =?us-ascii?Q?auzBez/praHSeSsoWjcoekCILM3ElZeLfYsl//2b21pSn+dIFMDiuX9B3NyJ?= =?us-ascii?Q?fyNKfEa+sVS8MNX9zBSLsIlx2MQFyM=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 6:dFsn0gNWctlxdg8oF5PZMDG8iBx9Vrnp1cz8ypzIVoGm9A4nXkh0SbDL4jZJiIujhEzLdBrDLkzK0hdT9BUbvJAy/uDLSTI0lkod+LKqcz2194h3VnV3rD9CywlJJRQDoPh9xDP0GSSypLZVBivzI73a3X9BwPK8QTMaIJPOaxxNq5pZKdY20weTmlgXHmdmGVNZhlezi3ytOqjnPU80ig+8dWa5sr1Ty13miKJp+dKcGg1SSrmP4r3bBeX5i8cb+UGTo95XQfdJvrGQ0S3lafBVdzcv9SURtP/4EQ0uylyb7mteOKaQQ/dkCIfj/XibYQbYA0Pva207DtWsqBT5K+1stBO5bKBTa/wkqU9WwSY=; 5:bmB8XkaeUnizxmAuiVyQDIZ4Puqz7ikUeKTIZ15ZSQgeu7DxfG+5Ai5+m9DLvjG5kmlBNaeTbXwR32ctKFRsr9tp5d6/1vOMT4jXdxVQXPFbJFR2GppSIrLkSSoL3JZxAujiRgVRbYa68WsHYG6sag9lGFe8YKTTzuUlGsX17PQ=; 24:30jR9O5jCu4r+L2AW9BBOX1UXd4fHsfGHeFXYnR+jO5bgQclxeQusRrO9hkK1c8O59c2eIGWowvG76eVWB2rmFw61PPwJJ6XPIcCAXHt2kw=; 7:GaJYshsCrJSOJQVbG0bEfUZ1GEpKxfEcFivAvTUM/oDn+17iLFB4v6H0GRm47iFLibLq3qPlXZgbrINSlY09ycFqEmTsqzf/NEqFzjpvbXLXN3LR91vazLN+FLS+qVztAjNkSzDd8mitFHZhsejaJS0V9Tjy5FzFToUIxPDkVCq5qyoGE3cNyFv8fnzF1pRXK3y83lhKDMpWQNdt9fUbDIWuNJ04liv+552f4gQMeCpE+s0IcsSKmtGMz76Gw8/s SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 18:48:07.8039 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1668fcc-6482-47be-5005-08d5369092af X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR04MB0703 Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 18:48:20 -0000 the set may be empty - still reject > On 28 Nov 2017, at 9:30 pm, Nikolai Malykh wrote: >=20 > May but not must. > What about certificate that contain IP address set only OR AS number = set only (not both)? >=20 > 2017-11-28 13:01 GMT+03:00 Geoff Huston : > Reject - in the context of resource certificates the resources may = contain > both IP addresses _AND_ AS numbers. >=20 >=20 >=20 > > On 28 Nov 2017, at 8:04 pm, RFC Errata System = wrote: > > > > The following errata report has been submitted for RFC6487, > > "A Profile for X.509 PKIX Resource Certificates". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5187 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Nikolai Malykh > > > > Section: 7.1 > > > > Original Text > > ------------- > > encompass > > Given two IP address and AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP = addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range = element > > within the set X. > > > > > > Corrected Text > > -------------- > > encompass > > Given two IP address or two AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP = addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range = element > > within the set X. > > > > > > Notes > > ----- > > > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6487 (draft-ietf-sidr-res-certs-22) > > -------------------------------------- > > Title : A Profile for X.509 PKIX Resource Certificates > > Publication Date : February 2012 > > Author(s) : G. Huston, G. Michaelson, R. Loomans > > Category : PROPOSED STANDARD > > Source : Secure Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG >=20 >=20 From nobody Tue Nov 28 17:16:31 2017 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 9C87612025C for ; Tue, 28 Nov 2017 17:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OrUyfyHJwSfu for ; Tue, 28 Nov 2017 17:16:28 -0800 (PST) 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 97275120724 for ; Tue, 28 Nov 2017 17:16:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eJqz9-0002ou-Bc; Wed, 29 Nov 2017 01:16:23 +0000 Date: Wed, 29 Nov 2017 10:16:20 +0900 Message-ID: From: Randy Bush To: Geoff Huston Cc: Nikolai Malykh , db3546@att.com, sidr@ietf.org, morrowc@ops-netman.net, robertl@apnic.net, George Michaelson , RFC Errata System In-Reply-To: <147D5A96-CCBE-422B-AA82-C12802256844@apnic.net> References: <20171128090411.26C0DB80C87@rfc-editor.org> <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> <147D5A96-CCBE-422B-AA82-C12802256844@apnic.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:16:30 -0000 > the set may be empty - still reject that is orthogonal. if you think the syntax even allows it, the text should handle the null set or sets. you may wish to read 4.8.10. IP Resources Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical. This extension contains the list of IP address resources as per [RFC3779]. The value may specify the "inherit" element for a particular Address Family Identifier (AFI) value. In the context of resource certificates describing public number resources for use in the public Internet, the Subsequent AFI (SAFI) value MUST NOT be used. This extension MUST either specify a non-empty set of IP address records, or use the "inherit" setting to indicate that the IP address resource set of this certificate is inherited from that of the certificate's issuer. >>> Original Text >>> ------------- >>> encompass >>> Given two IP address and AS number sets, X and Y, X >>> "encompasses" Y if, for every contiguous range of IP addresses >>> or AS numbers elements in set Y, the range element is either >>> "more specific" than or "equal" to a contiguous range element >>> within the set X. >>> >>> >>> Corrected Text >>> -------------- >>> encompass >>> Given two IP address or two AS number sets, X and Y, X >>> "encompasses" Y if, for every contiguous range of IP addresses >>> or AS numbers elements in set Y, the range element is either >>> "more specific" than or "equal" to a contiguous range element >>> within the set X. From nobody Wed Nov 29 12:21:18 2017 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 D4A8612426E for ; Wed, 29 Nov 2017 12:21:16 -0800 (PST) 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 Ywy8oyp-g4Db for ; Wed, 29 Nov 2017 12:21:15 -0800 (PST) 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 03F8F1241F3 for ; Wed, 29 Nov 2017 12:21:14 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id b123so6084905qkg.7 for ; Wed, 29 Nov 2017 12:21:14 -0800 (PST) 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=AOA0Qps19s4e/zdvNzkV6TedYJjK0xXn+yuemBlFU6E=; b=Eza9SmOsWlHhyq64hBPYELAwp5GmMEXmmXdhSrJsy5NGtkag6xJy/lay/HE09931O4 H76v4nWnjV5QbTJdycRDFNsR7J1V+QXCeYWJvRnjl0S4sHg/oF8cMdwHyYeGHSua8haG 8pd4bCDyTU560hRs3UmiWfVlEwfstQV2exoQo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AOA0Qps19s4e/zdvNzkV6TedYJjK0xXn+yuemBlFU6E=; b=oLXD/Fm8SfoeKYrFuTx6a27gfMo4JYwOCfw2Ptd4JgYy8O2KcsK9n0Dk+enkRWlWHh h09ShRb0FDH7WTfv/9FzlCFnI1hFzSNWdDAhRVpppX4NLlMrWaBBGbNQaH1yHDLoDiYJ Zxf0O4KUbgT+hlJzWOp25EPYB6SEZqrA07HdD86F2/Y2I7zE72Ckbdjj7meS+PYeEYdJ t5bfZjXJFCTr7FDm+d1yGMnjPG1N32BtZwdOK6mQ0ITqRt0KMbijVzOmwNbHnA26GdgR hZQfFKLxtzW0xC8/CwYuQPGcvH/rTpNCdfiKNreAaUwzXGcejL/41bCQ6qkWjFlAEhK5 mTOQ== X-Gm-Message-State: AKGB3mK6wL/d4DgNiRSxFYTX96JnpRu8cGX2oAZSL+Rl+ka7gUki1rAb HVzJc2NbEzVULNfH1MrSwbf4fQ== X-Google-Smtp-Source: AGs4zMYZd7kNa536Mk5NEzD5fCInxY1keOI50Gx3wnoqv5QypoIKlQWa3LYoZk9s4h/n7jBlqslEzA== X-Received: by 10.55.51.73 with SMTP id z70mr139157qkz.338.1511986874082; Wed, 29 Nov 2017 12:21:14 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id j129sm1761819qke.11.2017.11.29.12.21.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 12:21:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Sean Turner In-Reply-To: Date: Wed, 29 Nov 2017 15:21:12 -0500 Cc: RFC Errata System , nmalykh@gmail.com, sidr list , Chris Morrow , robertl@apnic.net, George Michaelson , Christopher Morrow Content-Transfer-Encoding: quoted-printable Message-Id: <8DB256D1-206E-4C40-9527-A0DDFDB920F2@sn3rd.com> References: <20171128141936.C689BB816F2@rfc-editor.org> To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5190) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 20:21:17 -0000 I think this one should be marked HFDU (Hold For Document Update). spt > On Nov 28, 2017, at 10:08, Christopher Morrow = wrote: >=20 > spare > seems spare... >=20 > On Tue, Nov 28, 2017 at 9:19 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5190 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 8 >=20 > Original Text > ------------- > 3) A randomly generated ASCII HEX encoded string of length 20 > or greater: > example: cn=3D"0f8fcc28e3be4869bc5f8fa114db05e1"> > (A string of 20 ASCII HEX digits would have 80-bits of > entropy) >=20 >=20 > Corrected Text > -------------- > 3) A randomly generated ASCII HEX encoded string of length 20 > or greater: > example: cn=3D"0f8fcc28e3be4869bc5f8fa114db05e1" > (A string of 20 ASCII HEX digits would have 80-bits of > entropy) >=20 >=20 > Notes > ----- > Typo >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Nov 29 12:23:26 2017 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 B46661241F3 for ; Wed, 29 Nov 2017 12:23:25 -0800 (PST) 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 IjhtaMCJOILP for ; Wed, 29 Nov 2017 12:23:23 -0800 (PST) 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 7F61712426E for ; Wed, 29 Nov 2017 12:23:23 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id i130so6114603qke.4 for ; Wed, 29 Nov 2017 12:23:23 -0800 (PST) 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=7XyxkK3y2kRzMbsgVImn1x8Byb+MOiDWbpPpkF5WOJA=; b=exFmAsZ4kARM2BCM6ZPsw1HEwKgViQ17lYQtHQvse8b2z1ia3YFnJnlRvV6ep6kajQ cp0ZXleS1AZcu+MDAaNybDY/jTRu3cTTSmfubk184kCo28qF96M6mB0UeJgeTby17olp bVbn/ntvS3XteAZOIhQXRD2D3AI6+zHB+ikwY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7XyxkK3y2kRzMbsgVImn1x8Byb+MOiDWbpPpkF5WOJA=; b=uY0sdHK8BlifMYOSPnbF8y2a/y3WwfrDPFu3a+CpsM80lxnqnxRtp9pS9KF9sWMUEu 0HB++BPiE+r8aOrnEgSRAdNTDBwL+XbEKzfHWmBcgj5S9nS1JpTbHQsNOq3zElSHKW/D lY3G5geBjEb96kF38BBXr/czb0Scog1osEFZqxAw3SopszMmTmIydk4a0sdmUGJ7e9+8 mAWj7rE4zu76Fl6lGnsZxqQlhF10ttRaEvjNk4R+zNoj3VFqWhujqOELZyN3WNAJxdX9 iGjQr2b+7jE9HXTqF6lxQMe/rtx2IuSiARj3JGvOOCUTL7ZaFmuTsDHItzFFyRdTJnwF biIg== X-Gm-Message-State: AKGB3mK9MEI0Dplf5WzrIJ56YdUcYl0Q4WfFYn0vpkAQhCTu+bfWA8h3 2Z/emG2UZbX76FucdUVHpbo4KQ== X-Google-Smtp-Source: AGs4zMbdpqJdARPl+0Q5XQxxjwqaJoeMkHcAbtAayIzaCJF8jezyC4PHqcH3W+ko73MhVsO8fgs1yw== X-Received: by 10.55.73.13 with SMTP id w13mr126259qka.201.1511987002622; Wed, 29 Nov 2017 12:23:22 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id u73sm1795554qki.7.2017.11.29.12.23.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 12:23:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Sean Turner In-Reply-To: Date: Wed, 29 Nov 2017 15:23:20 -0500 Cc: RFC Errata System , nmalykh@gmail.com, db3546@att.com, sidr@ietf.org, Chris Morrow , robertl@apnic.net, George Michaelson Content-Transfer-Encoding: quoted-printable Message-Id: <1D541E44-2B65-4B74-8E57-2D62BEF941A1@sn3rd.com> References: <20171128142820.41FB9B8174E@rfc-editor.org> To: Christopher Morrow X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5191) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 20:23:26 -0000 Yep, but mark it HFDU (Hold For Document Update). spt > On Nov 28, 2017, at 10:09, Christopher Morrow = wrote: >=20 > seems legit. >=20 > On Tue, Nov 28, 2017 at 9:28 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6487, > "A Profile for X.509 PKIX Resource Certificates". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5191 >=20 > -------------------------------------- > Type: Editorial > Reported by: Nikolai Malykh >=20 > Section: 8 >=20 > Original Text > ------------- > (The issuing CA may wish to be able to extract the = database > key or subscriber ID from the commonName. Since only the > issuing CA would need to be able to parse the commonName, > the database key and the source of entropy (e.g., a UUID) > could be separated in any way that the CA wants, as long = as > it conforms to the rules for PrintableString. The = separator >=20 >=20 >=20 >=20 > Huston, et al. Standards Track [Page = 21] >=20 > RFC 6487 Resource Certificate Profile February = 2012 >=20 >=20 > could be a space character, parenthesis, hyphen, slash, > question mark, etc. >=20 >=20 > Corrected Text > -------------- > (The issuing CA may wish to be able to extract the = database > key or subscriber ID from the commonName. Since only the > issuing CA would need to be able to parse the commonName, > the database key and the source of entropy (e.g., a UUID) > could be separated in any way that the CA wants, as long = as > it conforms to the rules for PrintableString. The = separator >=20 >=20 >=20 >=20 > Huston, et al. Standards Track [Page = 21] >=20 > RFC 6487 Resource Certificate Profile February = 2012 >=20 >=20 > could be a space character, parenthesis, hyphen, slash, > question mark, etc). >=20 >=20 > Notes > ----- > The closing parenthesis is missing. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6487 (draft-ietf-sidr-res-certs-22) > -------------------------------------- > Title : A Profile for X.509 PKIX Resource Certificates > Publication Date : February 2012 > Author(s) : G. Huston, G. Michaelson, R. Loomans > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Nov 30 05:05:27 2017 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 83F9F1293F3 for ; Thu, 30 Nov 2017 05:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 JE8eCwc4gjSC for ; Thu, 30 Nov 2017 05:05:22 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0114.outbound.protection.outlook.com [104.47.1.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7B21293F2 for ; Thu, 30 Nov 2017 05:05:21 -0800 (PST) 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=yWbtGwqasxXLpnxYvx3/Us/DrqmFNGOUxH9oWcnge+g=; b=hGCVEA1khp76kvD9CgWA4IjNWcvehzLBGhAj72xL6KoqoZXR2f4b8iGeTQFP2DYeXMz+CMlSV1NygtasvV/G93F1SgyOjVn0JbDubCE2GuUZQhwNGmOomx/2vukIyE1Q0Tximq+/Ft/dZufe69vPEQCNGjrC7867+XooKOQLqxg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.169.153.236) by DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Thu, 30 Nov 2017 13:05:18 +0000 Message-ID: <049901d369db$62a65aa0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Geoff Huston" , "RFC Errata System" Cc: , , , , , "George Michaelson" References: <20171128090411.26C0DB80C87@rfc-editor.org> <2D0550E2-5A6A-4C10-8B4A-74A1E88E1EC1@apnic.net> Date: Thu, 30 Nov 2017 12:18:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: [86.169.153.236] X-ClientProxiedBy: DB6P190CA0036.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::49) To DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) X-MS-Office365-Filtering-Correlation-Id: 747dbd16-b0c4-4c2d-35f7-08d537f301d1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603286); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:KvufGWi9OTdhnNH7vU5nLYo3h/hqyfTupMFgrQ3Ir/Tnjd2jvrFSf9f95KNIZpTAOrjFlyCNeb1BoZWgBz2018cB8VRtK5cLnMx2qE2O2YH56/JT+S2n8zQ0tIFazack6rzK0a95YT6jDHJcJPgFCJvKsQAh+Dbgv29qMkOtboqlUjvAGrON9aHxFVn8SrpEPWIM+BkDypPTnQWzbvfhnqD3bBuEbHFnjlcNInumRHGHSsfCEzM5rwR57bcValzr; 25:azgD98eiUUARwMfQrXmqxzL6zPsv1bAvudOQIEmzN68EQfkwAz94Tm0Myo/MKpNCE0pdoJKlhEfppVPca2Eon4bPDw3mfSSqk2EzC3XJcvPmiJFLz1gMnRvtVa0j0vFgiZAGJYoiITJnbSI+zf3euM1JBJJXCM1LqQwEag82GnXE0yoou/3hF0c/I6m0d0DQqJs+9jmoPu243zhUVdrvomhLpGIakRUsEM/HepFYh5CEn6qxRzZX6MRzzzA3qtOPHjY85mMqfcILtYLzVjW1clc8dUGWTi8Ak6Enb72/FnceX7K5qXoTUtI3Rzr5DsUOKu0EzmXwoLMDa/8x+j9xZQ==; 31:SumyJ52eZmTW3xl0KbksrlMNNERZcy4Q2dmzLW/8FG3UieK2O2ff1CnmKcRAb+9MrRBHDPNU1ygKWpUSIIsBtgf2fKukzGANEgg45t0ahTztw1cD2jlBcDAXbFb39Ml/3D232TVmkj4G5Rx+GHiL9ThE29llYqfIuWQ/4HWB2vANWL/S+WQnL9G6ApCes1hEM4D5KaCDB47LvsSEKy6UYxhZ7sr9HYBAZPtkxoqj4SI= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DB6PR0701MB2999: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(131327999870524); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(3002001)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 4:X7mKQ5A/czuECWv2dYoBGm9GOEjxeFSrSYg+x1txuKppvLdh3MbhlKK2xx6L6uj++jV4cu3Gx+B6CqF1Q3ds3mDMtk6ND71OZfaFTRQO79b6ZAnfObYSJHif+csUt0eD+xxDs02mExT04hbdGJWPpQHlodX9awD7CaeHbsoApD+K0OQP4D5wjiYWtXi2yEl2S7rLj22T8LEZj9I06Mzfddp39cAVcnFlheHmKf+Q+aftie/lbvgVhmVPaMYnvqm7e2bxeVLVVZtUADLv79nE2i5XziiAbHuH4F9Y378iDi5T0e6/us+n4C26D/6JMpKh X-Forefront-PRVS: 05079D8470 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(366004)(39860400002)(189002)(24454002)(199003)(13464003)(25786009)(39060400002)(52116002)(14496001)(81166006)(50466002)(54906003)(5660300001)(6246003)(4326008)(8676002)(16526018)(2906002)(81156014)(84392002)(6496006)(1556002)(6116002)(3846002)(966005)(230700001)(44736005)(116806002)(33646002)(6486002)(44716002)(86362001)(189998001)(68736007)(229853002)(6666003)(305945005)(1456003)(66066001)(97736004)(23756003)(8936002)(53936002)(316002)(9686003)(110136005)(62236002)(7736002)(478600001)(61296003)(101416001)(106356001)(53546010)(1720100001)(4720700003)(50986010)(81686010)(76176010)(47776003)(81816010)(50226002)(6306002)(105586002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; 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: =?iso-8859-1?Q?1; DB6PR0701MB2999; 23:3W2iRVpr+7ZNvE5KEr2Jlz1tKwi/I+fs96KGe?= =?iso-8859-1?Q?zOPN6BCNqjJNdlQdiW7jQHixh3p++mYk0TbBTwO5VVWmInI8Lf3UR+e7ws?= =?iso-8859-1?Q?WCV9Ea2bsx35fgf4Bizeoi1IcSvP+AhZc01c2RUbK27mKrnBk4uxVdptIm?= =?iso-8859-1?Q?O6fqqaRVNq/GNTr2g+9Ot2rADPs5FYmqYLi6r03PJEnX8cjRAtxBu6lMzE?= =?iso-8859-1?Q?sIpIMTII8EqAI50P9blmO8lVmcnV0jqKnDfN9XNHmWdu66fFzo/YrN5Z6d?= =?iso-8859-1?Q?TKwxzpdJQfXm2Yj0GeGrt7cSOtoftPd8TuYvO/KCxIce18CSAJC2dUItb9?= =?iso-8859-1?Q?LbkOYUhA7xR10jJgzBfmnsAOPsIS7K25a+butymT6QYyYHzk5UcY32QSYA?= =?iso-8859-1?Q?Vh86f/wjtz9apLGO9uBifwOaxoC2K2FRYco0FkdcgHdiVGE/0HTVaUNlQs?= =?iso-8859-1?Q?JwCXc58EZzP9zzL21UTRwpctqO5DoPy1UA/4DhuKRLhjkKQBwBdI7DLw0O?= =?iso-8859-1?Q?4Q1/b0p+kZlWpGzX+EaePem1/yy1COxC8kFEV5XjBWxLe57/UYf+oHt/st?= =?iso-8859-1?Q?yU5f5zXKst8YdnYhZM3V5NHocCbZfuaeb5QWTALSg6lD2faF179eKJVEt4?= =?iso-8859-1?Q?qXEY1sZLJRqU2wNXCWtgk4XfMpD5iZdMwhDSFFEVtjl0Nw4kBODLMyjpMf?= =?iso-8859-1?Q?+yMCI6eB7p+XPJsq27X5rKu6xXubSM6F7QrVFt74Im4z5d8mY51VPewtfu?= =?iso-8859-1?Q?sXzUHtRVZmzE05NMmzL3UIlVEbLTnBTEkx7D2xTjmIEScVWTbPZuwswLML?= =?iso-8859-1?Q?HVikmfCydvEG+L2hKKMe19lJT/iJCqt8LTfMeqfz5eaSN8NPE1kBl8P6ox?= =?iso-8859-1?Q?oAgjwdtHzlBMlpsmUFjVTr5AS7L9cE5NvgAWRmbnEo73PO657PbMoF34Op?= =?iso-8859-1?Q?pdNLv50AlhvNu5ZjW/UfZlIhQ0mkLZuLDMw6Nf7BLwgE128dwyP8E2Bm1s?= =?iso-8859-1?Q?c2laf9DSqAYgnVmtc4qy5KVICQrKIdABa8cJ4+U9YRx5xpqe1e1riHl35Z?= =?iso-8859-1?Q?4cttpI1+R0ojLlPDLwJYKnOppkTkE0YDBJs9YFchhQ9+8CnYJOq9RcQ6T9?= =?iso-8859-1?Q?coRospvXMY7UK0le6G6ds2vvmYSg2z1V0V2Ni2hbcxBBIeeacRSpbNXOJt?= =?iso-8859-1?Q?hK/25vQ0PXTW2QB50eVmcNo3FtCtClhon6agsXZ7W2D16lPfWqSKadrmOl?= =?iso-8859-1?Q?V6HRXd3G5+4e5Aaf+2JMFx5k01QY9RPrpI0F4dFsAgGw6UNckQXZEqI0+M?= =?iso-8859-1?Q?HTkTxTnOukbkJmlFU660vp2bjMbbs13u4hzzI1ProNJ1iTJZ0baG1GYwIJ?= =?iso-8859-1?Q?//jQm73vfCEZrtIhunUP9N3vQ0q+b8IqWbYQjMbLwHBPvUxQ8XVPvB6LZm?= =?iso-8859-1?Q?CEfnCeSF709h6v9iQlOrD5WoXYK/XkrDIyKwXmsODh+x95YS3GNel2uVcM?= =?iso-8859-1?Q?lfxPHXk6RLctJyiIbD7P4wLoQ2tcRtM6RyF9Bs/5zsqd3SRlN+Zru7FmX1?= =?iso-8859-1?Q?A25v5jniDQL+krWRQIQdiEXxtaedOWg0KYy5CHRbt1UFLgSeuHj91/R8RH?= =?iso-8859-1?Q?vv905HiAwyL8A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:dw9kSKnWG/R4xvUP/pg0upo3iRf3V/k142ceu0jwU2WqRjqT0OUxAn//rk6frDBgDtdXYggxuDd9r7oIAnIeHg4EEOGZNjZt1cDPp/i5OrNvAHGCR24qQS2is8i5yUXl7IrH4KbFdz/rwKifQHTk4Sxkug7IKyIZJM/v/uCz2WdIdwJL0iP7FxmZufWhqW88auZQafUGYTdpk+x68v20pfAQeyLFxtdNPBVDsUz5gkbFLEdqpKyEMw6VD1EaWbuH+/ecaenJ67tO4OdCu6rMjcEULm38WROXhz4cO2ezVxmhfM/xbmpjQj4Us4gkqjFA45HeaYiFtPzcx8Ma0G/V/Lyg3itW8YUWOFnaCIXOQrE=; 5:ccEHk5vVs4Qm5gJ3cVOx8xTrwP7DOTvo2lYsMvF5tZIKd8ca9nr1pk0rfXvomMoYdvv3BFg8b+BK46AmzgxaLAGqV527wXQuLN2mSKJDppN+7rHmQq15Iduv6w0khyxeeI7u2MNDajaSBcfXMWnGMbwPuRUctmSTyJcnSLiywoo=; 24:sTbMkYrLuDpLQahJ2rDfDYzXd94rUj7KMQwINsOi6EwhpN5/RqaOx6DWCT+e7vhyhPToqPJPZ+e3ShHyRF4KYo5fxizdjWl8x/4nJNJEowc=; 7:XrlUwnq74am3/Xz2xVNLp8XuKJuD4H55olUhrBUlbdi0tiyFF78TImf3dMnJBfCybkfdpXdISZTBIRdS7cPl7alKg8d6Y8nwlyW9sBAjMOGWDZdlHywniNUVXV1Kejzn6qdord1Rc51UYssDwzye6w82/MKy9nrWJLX92yrWr4qJOLgSr52Qlhe+6PB87+PT5faiVFZrOt2PqBQeZI5v1j9SVaJUmnWTHusTMeM3TvVU/TgF35PhAwO0tmLbbPWJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2017 13:05:18.4393 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 747dbd16-b0c4-4c2d-35f7-08d537f301d1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: Re: [sidr] [Editorial Errata Reported] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 13:05:25 -0000 ----- Original Message ----- From: "Geoff Huston" Sent: Tuesday, November 28, 2017 10:01 AM > Reject - in the context of resource certificates the resources may contain > both IP addresses _AND_ AS numbers. Precisely; it is a 'may' whereas the current text "Given two IP address and AS number sets," has overtones of requiring both to be present. The later phrase, "for every contiguous range of IP addresses or AS numbers elements in set Y," does imply one or the other or both, so I am on the side of 'Accept'. Note, too, that the two earlier definitions, ' more specific' and 'equal', both say " Given two contiguous IP address ranges or two contiguous AS number ranges, ..." Why should 'encompass' be different? Tom Petch > > On 28 Nov 2017, at 8:04 pm, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC6487, > > "A Profile for X.509 PKIX Resource Certificates". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5187 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Nikolai Malykh > > > > Section: 7.1 > > > > Original Text > > ------------- > > encompass > > Given two IP address and AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range element > > within the set X. > > > > > > Corrected Text > > -------------- > > encompass > > Given two IP address or two AS number sets, X and Y, X > > "encompasses" Y if, for every contiguous range of IP addresses > > or AS numbers elements in set Y, the range element is either > > "more specific" than or "equal" to a contiguous range element > > within the set X. > > > > > > Notes > > ----- > > > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6487 (draft-ietf-sidr-res-certs-22) > > -------------------------------------- > > Title : A Profile for X.509 PKIX Resource Certificates > > Publication Date : February 2012 > > Author(s) : G. Huston, G. Michaelson, R. Loomans > > Category : PROPOSED STANDARD > > Source : Secure Inter-Domain Routing > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr