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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
