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
signature.asc
Description: Message signed with OpenPGP using GPGMail