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

[Stephen Farrell <[e-mail]>]

Hiya,

On 04/01/17 22:15, Rob Austein wrote:
> At Wed, 4 Jan 2017 20:57:24 +0000, Stephen Farrell wrote:
>> On 04/01/17 20:04, Rob Austein wrote:
> ...
>>> 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.
> 
> The theory, such as it is, goes:
> 
> * RPKI is a tightly constrained profile of X.509v3, with almost
>   everything either required or forbidden, to reduce the number of
>   grey areas.
> 
> * The BGPSEC profile is a minimal set of changes and extensions to the
>   RPKI profile: same overall goal, slightly different constraints.
> 
>> 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.
> 
> Well, strictly speaking the subject name is always selected by the
> issuer in X.509, but I know what you mean.
> 
> RFC 6487 is weird about this because various parties were extremely
> concerned to avoid anything that could be construed as certification
> of real-world identity, ie, they did not want to find themselves in
> the mainstream PKI business.  So RPKI uses meaningless names and has
> the ability to enforce that, hence the text you note in RFC 6487.

I'd say any concerns that the web PKI CAs might have had ought
now be ameliorated (or OBE, give letsencrypt), so not trodding
on mainstream CA business is probably not as much as concern
as was the case at the start of the RPKI work.

> 
> RFC 6487 6.1.1 does in fact allow the subject to include a subject
> name in the PKCS #10 request, but the text is loaded with weasel
> words.  Speaking as someone who has implemented all of this, I find
> the RFC 6487 constraints on subject name in PKCS #10 requests a bit
> excessive, but that's not the document currently under discussion.

Well, except that this draft does re-iterate some of those now
clearly weird MUSTs.

> 
>> (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?)
> 
> The OpenSSL command line tool would probably fight hard against either
> omitting the subject field from the PKCS #10 request or allowing it to
> be NULL.  The former (field absent) is not even syntactically legal
> X.509.  The latter (present but NULL) is legal but kind of unusual:
> RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty
> subjectAltName extension is present, RFC 2986 is silent on the subject
> and is only informational in any case.
> 
> I'm pretty sure that the OpenSSL library would allow the
> present-but-NULL form, but haven't tested it (recently? ever? don't
> recall...).
> 
> In practice, I don't think any of the RKI CA implementations reject
> PKCS #10 requests for having a non-NULL subject, they just ignore it.
> 
> All of this is still a problem with RFC 6487, which we should have
> caught five years ago.  Oops.  Not sure what the best approach is when
> trying to sub-profile a profile with a known wart like this.

Fair point.

So assuming there isn't a chorus of WG participants asking to
remove the weird constraints then I'd say the right thing must
be to not re-iterate any weirdness from 6487 but to only inherit
that by reference. That way, if/when we modify 6487, we won't
have to do the same with this, and maybe also hit problems
with these constraints being enforced by code in two places.

I think the only such text I saw (that re-iterates 6487) was
in 3.1.1 but there might I guess be more.

> 
>>>> 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.
> 
> Fair point.
> 
>> 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.)
> 
> Has been discussed, somewhat noisily.  Ask a SIDR WG chair if you want
> an opinion on WG consensus.  My own take is that router keys probably
> get whacked on roughly the same kind of timescale as other RPKI keys,
> so if the revocation mechanism is good enough for everything else,
> it's probably good enough for router keys.  YMMV.

Fair enough. Again, assuming that there's no chorus wanting
change, I'll clear this point as well.

Cheers,
S.

> 
>>> 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.)
> 
> It's sort of in RFC 6810 (rpki-rtr).  The update to RFC 6810 is
> stalled because I dropped the ball last year.
> 
>>> 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;-)
> 
> I had front-row tickets to the "let's stuff routing policy data into
> the DNS!" show back in the '90s.  My main take-away from that mess was
> a fear of real-time circular dependencies.
>