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

[Rob Austein <[e-mail]>]

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.

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.

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

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

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