Re: [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
Jari Arkko <jari.arkko@piuha.net> Thu, 05 January 2017 11:10 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58312946E; Thu, 5 Jan 2017 03:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 a8GvAqXloNfy; Thu, 5 Jan 2017 03:10:41 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCF412943F; Thu, 5 Jan 2017 03:10:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9C1852D291; Thu, 5 Jan 2017 13:10:40 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVm8NeDMpQ1k; Thu, 5 Jan 2017 13:10:40 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id F3D9B2D290; Thu, 5 Jan 2017 13:10:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Subject: Re: [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_454B6028-C164-4E50-B231-A60C76316BBB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jan 2017 13:10:39 +0200
Message-Id: <AA19FD72-E9F8-4CC5-BC21-D5CCDFB9C53E@piuha.net>
References: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com>
To: Dale Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nnj3UEU8B6Ouru3TKgswuo3tPFY>
Cc: gen-art@ietf.org, draft-ietf-sidr-bgpsec-pki-profiles.all@ietf.org, ietf@ietf.org, sidr@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 11:10:43 -0000
Dale, all, Thanks for the review, re-review, and changes. I’m posting a No Objection position for this draft in today’s IESG telechat. But: > 3.1.1. Subject > > However, each > certificate issued by an individual CA MUST contain a Subject name > that is unique to that CA context. > > E-mail from Sean Turner on 22 Dec 2016 says: > > I think this is just a case of a missing "CA" in front of the > word > "context" so tweaking it to: ".... that is unique to that CA > context". The certs only need to be unique on a per CA basis the > subject name does not need to be unique across the whole of the > RPKI. The combination of issuer+subject+serial # plus all the > parent certs provides the uniqueness. > > However, there doesn't seem to be a standard meaning of the phrase > "CA > context". I can't find any occurrences in any RFC or in any I-D > other > than draft-ietf-trans-threat-analysis-NN. Is a good question. > It seems to me that the best solution is to put a cleaned-up version > of Sean's statement "The combination of issuer+subject+serial # plus > all parent certs provides the uniqueness." into the draft, as that is > admirably clear. (Unless, of course, there is a standard PKI phrase > for that requirement, in which case that could be used.) For > instance: > > However, the combination of subject name, serial number, issuer, > and certification path must be globally unique. That would be clearer for me, assuming that is what was actually meant, of course :-) > 3.3. BGPsec Router Certificate Validation > > The validation procedure used for BGPsec Router Certificates is > identical to the validation procedure described in Section 7 of > [RFC6487] (and any RFC that updates this procedure), as modified > below. For example, in step 3: "The certificate contains all > field > that must be present" - refers to the fields that are required by > this specification. > > This picks up the changes from Sean Turner's e-mail of 22 Dec 2016 > except it omits changing "that updates this procedure" to "that > updates that procedure", which seems to me to necessary to make the > wording correct. I think that’s right. > step 3: "The certificate contains all field that must be present" > > This doesn't match the text in RFC 6487, despite claiming to be > quoted: > s/all field/all fields/ and s/must/MUST/. Right. > 7. IANA Considerations > > No IANA allocations are request of IANA, ... > > I think this should be "No IANA allocations are requested of IANA", > or > probably better "No allocations are requested of IANA". > > E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar > comment on the IANA considerations and he suggested the first > option.", but no change has been made. OK Jari