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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
