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

[Stephen Farrell <[e-mail]>]

Hi Rob,

On 04/01/17 20:04, Rob Austein wrote:
> [Not the author, but...]
> 

No matter - a good answer is a good answer:-)

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

Hmm. I wonder if that's the best plan, especially if there's
no interop justification for some of it. I note that 6487
says "In the RPKI, the subject name is determined by the
issuer, not proposed by the subject" but that seems a bit
weird for routers, where I would guess there'll be more
diversity in terms of key/CSR generation code. (Correct me
if I'm wrong but I'm not sure if it's possible to conform
to these requirements with e.g. openssl, or is it?)

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

I'd wonder if that means some revocation request protocol will be
needed later. But it's fine to not try define that now.

More to the point is whether or not the WG have thought about the
revocation support in the RPKI and whether or not that seems also
ok for BGPsec. (I'm unsure myself, but mostly due to the number of
moving parts in the RPKI.)

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

So if that's a widely shared view of WG participants then it'd be
good to see it described somewhere to help implementers. (It may
be in the -overview document which I've yet to read.)

> Requiring the routers to speak OCSP seems
> like a potentially dangerous layering violation.

Not sure about a layering violation but I can see it'd likely be
problematic;-)

Cheers,
S.