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

[Rob Austein <[e-mail]>]

[Not the author, but...]

At Wed, 04 Jan 2017 05:51:20 -0800, Stephen Farrell wrote:
...
> 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.)

This draft is a profile of RFC 6487, which is itself a profile of RFC
5280.  All of the above is pretty much verbatim from RFC 6487.

> (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.

Yes, I think this too is inherited from RFC 6487.

> 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?

Not as such.  Fair question, but the architecture kind of assumes that
the RPKI RP process is separable from the BGPSEC implementation per
se, BGPSEC just consumes the output of that process.

Most likely implementation technique does all the RPKI stuff per se on
a separate box and just stuffs the resulting raw keys into the router
using the rpki-rtr protocol, so the router itself probably would not
have the information needed to play OCSP even if it wanted to do so,
which it probably doesn't.  Requiring the routers to speak OCSP seems
like a potentially dangerous layering violation.