Review of draft-ietf-sidr-bgpsec-pki-profiles-19
Dale Worley <worley@ariadne.com> Tue, 03 January 2017 16:15 UTC
Return-Path: <worley@ariadne.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4595129A65; Tue, 3 Jan 2017 08:15:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley <worley@ariadne.com>
To: gen-art@ietf.org
Subject: Review of draft-ietf-sidr-bgpsec-pki-profiles-19
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148346011373.28055.14231244831041167421.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jan 2017 08:15:13 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_mhwNPkKlWtt3QSn4O-btbOHfKY>
Cc: 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
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: Tue, 03 Jan 2017 16:15:13 -0000
Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-pki-profiles-19 Reviewer: Dale R. Worley Review Date: 3 Jan 2017 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The draft is much improved relative to the Gen-ART review of -18, but a few items remain. 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. 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. 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. 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/. 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. Dale