[sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-bgpsec-pki-profiles-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------



I have a few probably quick things I'd like to discuss for
this one:

(1) 3.1.1: Why MUST a CA ensure that the CA name and
Subject name combination is unique? I don't see what'd
break in BGPsec if that rule is omitted, but maybe I'm
missing something. 

(2) 3.1.1: Similarly, I'm not clear why only common name
and serial number are allowed in Subject.  Why is that
needed for interop? (I can see that you want to say that
code MUST support those but not why you want to prevent
other things.)

(3) Where's certificate status checking covered? What's
expected for BGPsec router certs? If BGPsec speakers are
intended to inherit the CRL checking from 6487 then being
explicit about that would probably be worthwhile.  And I'd
wonder if router cert revocation will be more common than
for other resource certs, in which case an OCSP-like
system could be needed - did the WG consider that?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- section 2: I think this is a bit badly written: "The use
of BGPsec Router Certificates in no way affects RPKI RPs
that process Manifests and ROAs because the public key
found in the BGPsec Router Certificate is used only to
verify the signature on the BGPsec certificate request
(only CAs process these) and the signature on a BGPsec
Update Message [ID.sidr-bgpsec-protocol] (only BGPsec
routers process these)." Do you mean that there's no way
that an entity can confuse a Manifest, ROA, CSR or BGPsec
update so there's no issue with which public keys are used
to verify the signatures on those data structures?

- section 3: As noted in my comments on the BGPsec
protocol, it'd be better to call out the SKI here if you
don't add the direct ref to 6487 to the BGPsec protocol
draft.