Re: [sidr] about the thread "Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487"

[Sean Turner <[e-mail]>]

On Jul 01, 2014, at 18:29, Rob Austein <[e-mail]> 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