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

From: Rob Austein <[email-masked]>
Date: Fri, 21 Feb 2014 18:30:23 -0500

Obscure little conflict that only an implementor would notice: there's
a three-way conflict between the current rtr-keying draft, the current
bgpsec-pki-profile draft, and the base RPKI certificate profile RFC.

The problem is with router-ids and the subject field in the PKCS #10
request.

- draft-ietf-sidr-bgpsec-pki-profiles-06 3.1.1.1 (talking about
  certificates, not certificate requests) says router certificate
  names SHOULD be /commonName=ROUTER-aaaaaaaa/serialNumber=rrrrrrrr,
  where aaaaaaaa is the ASN and rrrrrrrr is the router-id, as 32-bits
  hex in both cases.  OK, fine.

  As far as I can tell, this is the only way in which the router-id is
  encoded anywhere in the certificate.

- draft-ietf-sidr-bgpsec-pki-profiles-06 3.2 says that the certificate
  request profile matches RFC 6487 with a few specific differences,
  none of which have anything to do with subject names.

- draft-ietf-sidr-rtr-keying-04 3.1 says that when a router is
  generating keys, it includes the router-id in the PKCS #10.

  Given that the only place we have to encode the router-id is in the
  subject name (as opposed to, say, a newly-defined X.509v3
  extension), this text would seem to imply that the PKCS #10 includes
  a non-empty Subject field.

- RFC 6487 6.1.1 says that the Subject field of the PKCS #10 MUST be
  absent or empty except when requesting reissuance of an existing key
  and even then only if the CA's CPS allows reusing subject names.

I see no way to reconcile all of this without changing something.

What's an implementor to do?

For the moment, I've gone with rtr-keying and am allowing the subject
name to appear in the PKCS #10.  Not sure this is right, one could
make a case either way.  I can certainly implement it either way, but
it would be nice to settle this so I know which way to go.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Feb 2014 11:41:59 -0500

Rob,

Good catch.
>    encoded anywhere in the certificate.
yep.
>    none of which have anything to do with subject names.
yep.
>    generating keys, it includes the router-id in the PKCS #10.
this seems to be the place where there is an error, given you 
observation re 6487, 6.1.1.
> I see no way to reconcile all of this without changing something.
a router cert is issued by an ISP to one if its routers. it's not clear to
me that a PKCS #10 request is strictly required for this, as it is a 
local process
within an AS. But, if one does use PKCS #10 then a CA operating within an
AS context can probably determine the ID of the router making the request.
I suggest this mismatch ought to be addressed in the rtr keying I-D.

Steve