On Jul 01, 2014, at 18:29, Rob Austein <[email protected]> wrote: > 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.
+1 >> 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. +1 > 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. Yep the CA is the one attesting to the binding so it gets the final say. > 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. Just le me know which route you want to take (no pun intended) wrt draft-ietf-sidr-rtr-keying and draft-ietf-sidr-bgpsec-pki-profiles. spt _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
