At Fri, 27 Jun 2014 16:50:12 -0400, Sandra Murphy wrote: > > 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.
Right. I think it's reasonably clear that, on this point, RFC 6487 just needs to be fixed, as it violates the base specification. > 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. [...] I think the simplest approach is to allow router key PKCS #10 requests to include both the router id and the ASN(s). The need to support multiple ASNs (rare, but possible, if I understand correctly) means that we can't just use the subject name hack for this, since the proposed encoding of router ID and ASN into the subject name only supports one ASN. So I think we should: - Allow a non-empty subject name in the router certificate PKCS #10, said name to follow whatever we pick for the recommended form of the expected resulting certificate (ROUTER-<asn>,<router-id> or whatever), where the <asn> here is usually the one-and-only ASN but, if there's more than one, is whichever ASN seems good to the router operator. - Allow the ASIdentifiers extension in the router certificate PKCS #10. I don't particularly care whether we require this to be present in all cases or only in the multi-ASN case, but if it is present at all, the ASN encoded in the subject name MUST also be listed in the ASIdentifiers extension. The CA, of course, is free to reject this PKCS #10, or issue a certificate using the public key from the PKCS #10, a different subject name than proposed in the PKCS #10, or only certify a subset of the ASNs requested in the PKCS #10. Final decision on what to certify remains with the CA, the PKCS #10 is just a mechanism for conveying data to the CA in a tidy package. Note that the multi-ASN case could be construed as an argument for dropping the ASN out of the router certificate name entirely, or perhaps only dropping the ASN out of the name when dealing with a multi-ASN certificate. I have no strong feelings on the matter. I do not particularly care whether the PKCS #10 profile for router certificates is based on RFC 6487 or is a free-standing document; whichever is easiest to get right in a reasonable period of time. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
