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

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to