Rob,
Good catch.
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.
yep.
- 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.
yep.
- 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.
this seems to be the place where there is an error, given you
observation re 6487, 6.1.1.
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.
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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
