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