Subject: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487"

From: Sandra Murphy <[email-masked]>
Date: Fri, 27 Jun 2014 16:50:12 -0400

As we read the thread, there were two conclusions.

RFC6487 6.1.1 (how to send a cert request in PKCS) says

     Subject
        This field MAY be omitted.  If present, the value of this field
        SHOULD be empty (i.e., NULL), in which case the CA MUST
        generate a subject name that is unique in the context of
        certificates issued by this CA.

a)  "This field MAY be omitted." is wrong.  PKCS#10 does not say that the subject field is optional.  So an implementation that did omit this field might not work with a CA's implementation.

b) "If present, the value of this field SHOULD be empty" means that the rtr-keying draft was (at the time) non-compliant - rtr-keying said to put the "router number" in the subject field of a PKCS#10 cert request.  

The bgpsec-pki-profile draft says that the subject of a router cert has the router ID in it.

The subsequent revisions of the rtr-keying draft no longer put the subject name in the PKCS#10 request, in response to b).  

But that leaves us with no way to get the router ID communicated to the CA to put into the router cert.

1 We could presume the CA just "knows".
2 We could invent some other way to communicate (and secure) the router ID bundled with the PKCS#10 request.
3 We could remove the meaningful subject name in the router cert.
4 We could change the "the value of this field SHOULD be empty" text in RFC6487 to add an exception for router certs.  That would allow the PKCS#10 subject name to be non-empty so it could carry the router ID in the subject name. 

(Steve Kent doubted the need for using PKCS#10 to request a cert in the first place, so some other cert request mechanism is yet another option, though more work.)

Whichever we choose, some draft has to change or be written.

So speak up!

--Sandy, speaking for the wg co-chairs

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 27 Jun 2014 17:10:04 -0400

Speaking only as regular ol' member.

> 4 We could change the "the value of this field SHOULD be empty" text in RFC6487 to add an exception for router certs.  That would allow the PKCS#10 subject name to be non-empty so it could carry th…

I like 4.

bgpsec-pki-profiles is already updating RFC6487 - we could just include this in the update.

And it could take care of the errata issue also.

--Sandy, speaking as regular ol' member

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Jun 2014 09:53:49 +0900

imagine i go to my router cloud, a small one, say 42 routers, and tell
them to each gen a key, pkcs#10 it, and hand me the pkcs#10.  i take the
small bag of pkcs#10s and tell the ca to bulk sign please.  the ca needs
three router-specific bits of info
  a - AS (remember i could be running a confed or other aliasing hack)
  r - RouterID
  k - keying glorp signed by router

[ you omitted the as number in your discussion, but ca needs a so it
  knows which AS signs.  luckily bgpsec-pki-profiles does have it in the
  pkcs#10 subject ]

note that all sort of folk will need the a and r in the resulting pkcs#7
in order to select which key to use.  my scripts will need a and r to do
give the pkcs#7 to the management station(s) or the routers.  more
significantly, each router's peers will need to know which router cert
to grab from the rpki to validate the signature.

> 1 We could presume the ca just "knows".

i go to the ca and one by one, type a and r in for each request, and
hand it the k.  this scales really well, errors will never happen, and
cash will fall from the sky

> 2 We could invent some other way to communicate (and secure) the
> router ID bundled with the PKCS#10 request.

so a, r, and k go inside some sort of wrapper to code driving the ca.  i
suspect i would like the wrapper signed by g's corresponding private
key.  we could call this wrapped package pkcs#100

> 3 We could remove the meaningful subject name in the router cert.

which still leaves me needing to communicate a and r to the ca.  seems
like your choice 1 to me.

> 4 We could change the "the value of this field SHOULD be empty" text
> in RFC6487 to add an exception for router certs.  That would allow the
> PKCS#10 subject name to be non-empty so it could carry the router ID
> in the subject name.

that's a, b, and k.  the ca has all it needs.  yummy.

so, imiho, 1 and 3 are not viable.  2 and 4 are viable, but 4 requires
less work and invention than 2.

randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2014 11:27:03 -0400

Sandy,

Thanks for continuing to pursue this issue.

If we go with #4 below, I think your proposed revision makes sense.

I've seen Randy's comments on the other 3 options, so #4 seems to be at
the top of that list, now.

I did suggest we might use other cert request mechanisms. EST is the 
obvious,
current, standards-based option for this,  if folks want to consider 
alternatives to
PKCS#10. Since it was authored by a Cisco guy, there is some chance it 
might become
available in their routers. I would suggest this path only for router 
certs, not for
the RPKI certs. That might make it unpalatable, as a CA operated by an 
ISP would have
to deal with two cert request formats: PKCS#1- for child CA certs (if 
the ISP is not
a stub in the RPKI tree) and EST for router certs.

I'm just pointing out options.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 30 Jun 2014 18:09:52 -0400

>  knows which AS signs.  luckily bgpsec-pki-profiles does have it in the

That's a good point.

Actually, bgpsec-pki-profiles does NOT have it in the PKCS#10 subject.

bgpsec-pki-profiles gives a list of exceptions to the PKCS#10 defined in RFC6487, but the exceptions do not include the AS number. 

I had forgotten (if I ever noted) that the PKCS#10 profile in RFC6487 does not include the number resources.

So we need to come up with a way to get the AS number to the CA, also.

> that's a, b, and k.  the ca has all it needs.  yummy.

We don't yet have the "a" part of this.  Work to be done.

> less work and invention than 2.

Except for the point you made about the AS number.