Telechat Review of draft-ietf-sidr-bgpsec-pki-profiles-19

Request Review of draft-ietf-sidr-bgpsec-pki-profiles
Requested rev. no specific revision (document currently at 21)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-03
Requested 2016-12-04
Authors Mark Reynolds, Sean Turner, Stephen Kent
Draft last updated 2017-01-03
Completed reviews Genart Last Call review of -18 by Dale Worley (diff)
Secdir Last Call review of -19 by Yaron Sheffer (diff)
Opsdir Last Call review of -21 by Will LIU
Genart Telechat review of -19 by Dale Worley (diff)
Assignment Reviewer Dale Worley 
State Completed
Review review-ietf-sidr-bgpsec-pki-profiles-19-genart-telechat-worley-2017-01-03
Reviewed rev. 19 (document currently at 21)
Review result Ready with Nits
Review completed: 2017-01-03


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


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

   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.