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