Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487

From: Sean Turner <[email-masked]>
Date: Fri, 4 Apr 2014 11:41:06 -0400

On Feb 24, 2014, at 11:41, Stephen Kent <[email-masked]> wrote:

> Rob,
> 
> Good catch.
>> 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.
> yep.
>> - 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.
> yep.
>> - 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.
> this seems to be the place where there is an error, given you observation re 6487, 6.1.1.
>>   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.
> a router cert is issued by an ISP to one if its routers. it's not clear to
> me that a PKCS #10 request is strictly required for this, as it is a local process
> within an AS. But, if one does use PKCS #10 then a CA operating within an
> AS context can probably determine the ID of the router making the request.
> I suggest this mismatch ought to be addressed in the rtr keying I-D.

Finally getting back around to this.

Two points I think need to be made:

1. Can you omit the subject name from a PKCS#10?

I don’t think so. The syntax for PKCS#10 is [1]:

CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

Note there’s no “OPTIONAL” after Name.  It could be pretty easily argued that completely omitting the field would result in a non-interoperable certificate request; that is a certificate request that CAs might choke on because at a minimum they’re expecting a NULL subject name.  Based on this I think the text in RFC 6487 might need to be tweaked based on not being able to omit subject from PKCS#10:

OLD:

  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.

NEW:

  Subject
      This field is mandatory and MUST be included; however,
      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.

2. Is rtr-keying correct in stating the following in s3.1 because the text there is about initial provisioning not rekey/renewal and it contradicts the 2nd sentence about subject in RFC 6847?

s3.1 rtr-keying:

   … to generate the PKCS#10 request that includes the router number and
   public key ...

s6.1 RFC 6487:

     This field is allowed to be
     non-empty only for a re-key/reissuance request, and only if the
     CA has adopted a policy (in its Certificate Practice Statement
     (CPS)) that permits reuse of names in these circumstances.

I’m wondering how the router is going to know what value to use.  I suspect its only going to know what value to use after it has been told the value :)  Not including a router # in the request is probably okay if the request comes through the CLI session the operator is using to talk to the router because it can capture the request and "tag it" in someway to know what name ought to go in the subject field of the issued certificate.  But, say the CLI session isn’t used and the router uses its network connectivity to communicate with the CA.  If there’s no name in the request, how will the CA know what name to include in the issued certificate?  Seems to me like for that scenario, we’d actually want the subject name present in the PKCS#10.  Thoughts?

spt

[1] http://datatracker.ietf.org/doc/rfc2986/

---

From: Rob Austein <[email-masked]>
Date: Fri, 04 Apr 2014 13:12:53 -0400

At Fri, 4 Apr 2014 11:41:06 -0400, Sean P Turner wrote:
> I don t think so. The syntax for PKCS#10 is [1]:
> 
> Note there s no  OPTIONAL  after Name.  It could be pretty easily
> argued that completely omitting the field would result in a
> non-interoperable certificate request; that is a certificate request
> that CAs might choke on because at a minimum they re expecting a
> NULL subject name.

I agree.

One might reasonably wonder why none of the existing implementations
are choking on this.  The answer appears to be that we are all quietly
violating RFC 6487 on this point and nobody noticed.  Oops.

- My up-down client (which is, I think, the only client against which
  all of the up-down servers have been tested) includes a subject name
  in the PKCS #10 request, more by accident than by intent -- since,
  until router certificates came along, subject names in RPKI
  certificates were meaningless by design, the internal API constructs
  appropriate meaningless subject names as needed when the caller
  doesn't supply them, and I forgot to disable this for the specific
  case of PKCS #10 requests in the up-down protocol.

- The fact that this has never caused an interoperability problem
  strongly suggests that none of the servers are checking for this
  (meaningless) subject name in the PKCS #10.  I've confirmed that
  mine doesn't check: I do check all the required and forbidden
  extensions and so forth, but completely ignore the incoming PKCS #10
  subject name (ie, neither check it nor use it for anything later).
  
  I haven't done a code dive on any of the other implementations, but
  behavior on the wire to date suggests that we all ignore the subject
  name that RFC 6487 says should not be there.

So, again: oops.  But this does tend to support your analysis.

>  Based on this I think the text in RFC 6487 might need to be tweaked
>  based on not being able to omit subject from PKCS#10:
> 
> OLD:
> 
>   Subject

This seems reasonable, and, given the current apparent behavior, seems
unlikely to cause any problems.

> 2. Is rtr-keying correct in stating the following in s3.1 because
> the text there is about initial provisioning not rekey/renewal and
> it contradicts the 2nd sentence about subject in RFC 6847?
> 
> s3.1 rtr-keying:
> 
>      to generate the PKCS#10 request that includes the router number and
>    public key ...
> 
> s6.1 RFC 6487:
> 
> I m wondering how the router is going to know what value to use.  I
> suspect its only going to know what value to use after it has been
> told the value :)  Not including a router # in the request is
> probably okay if the request comes through the CLI session the
> operator is using to talk to the router because it can capture the
> request and "tag it" in someway to know what name ought to go in the
> subject field of the issued certificate.  But, say the CLI session
> isn t used and the router uses its network connectivity to
> communicate with the CA.  If there s no name in the request, how
> will the CA know what name to include in the issued certificate?
> Seems to me like for that scenario, we d actually want the subject
> name present in the PKCS#10.  Thoughts?

The authors of RFC 6487 can speak for themselves, but I think their
intent was to avoid requests for "vanity names" (CN="Joe's Pizza"
instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which could
be construed as eroding claims that the RPKI attests only to things
like addresses and autonomous system numbers.

---

From: Geoff Huston <[email-masked]>
Date: Sat, 5 Apr 2014 06:47:53 +1100

> like addresses and autonomous system numbers.

As I recall the discussion at the time was based around a desire to
avoid any implication that the CA was attesting as to the identity of the
subject. i.e. the CA was explicitly not saying that the holder of the public
key was the individual described int subject field (section 4.5 of RFC6487).

There was also some convenience in using a subject name that was linked
to the subject's public key, in so far as when the subject rolled keys
then the subject would request a new certificate and the issuer would
use a different subject name (section 4.5 once more).

Geoff

---

From: Randy Bush <[email-masked]>
Date: Sat, 05 Apr 2014 10:33:09 +0900

>> instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which
>> could be construed as eroding claims that the RPKI attests only to
>> things like addresses and autonomous system numbers.
> avoid any implication that the CA was attesting as to the identity of
> the subject. i.e. the CA was explicitly not saying that the holder of
> the public key was the individual described int subject field (section
> 4.5 of RFC6487).

except i vaguely remember a proposal to have there be special privileged
names for the certs of the rirs.

randy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 09:50:32 -0400

Randy,

> names for the certs of the rirs.
I floated that idea at one time, long, long, ago, but it is not in
the RFC, and I don't believe it is true in practice (although I admit
that I have not checked, personally).

Steve