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

From: Sandra Murphy <[email-masked]>
Date: Tue, 1 Jul 2014 07:36:25 -0400

On Jun 30, 2014, at 6:09 PM, Sandra Murphy <[email-masked]> wrote:

> 
> So we need to come up with a way to get the AS number to the CA, also.
> 

To continue this thought…

There's a list in RFC6487 of the certificate extensions that are allowed in the PKCS#10 request.

Is there any reason why we could not just include the AS Resources extension in the list of allowed extensions in the/a PKCS#10 request?  AS Resources is a list, which is what is needed.  

Would that be the right authority relationship?  (the router is the authority for saying what AS(ASs) the router uses?)

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 11:56:32 -0400

Sandy,
> Would that be the right authority relationship?  (the router is the authority for saying what AS(ASs) the router uses?
I would not say that the router is the authority; the operator is the 
authority, and the operator
should be controlling the CA. Still, the router could include the AS 
list in the request, and
the CA could filter it to match it's config database.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Jul 2014 12:02:38 -0400

Sandy,
> On Jun 27, 2014, at 8:53 PM, Randy Bush <[email-masked]> wrote:
>
>> [ you omitted the as number in your discussion, but ca needs a so it
>>   knows which AS signs.  luckily bgpsec-pki-profiles does have it in the
>>   pkcs#10 subject ]
> That's a good point.
>
> Actually, bgpsec-pki-profiles does NOT have it in the PKCS#10 subject.
>
> bgpsec-pki-profiles gives a list of exceptions to the PKCS#10 defined in RFC6487, but the exceptions do not include the AS number.
>
> I had forgotten (if I ever noted) that the PKCS#10 profile in RFC6487 does not include the number resources.
>
Thinking about this some more: note that a CA generally needs to have 
some way of linking a
cert request to a specific entity, person or thing. In this context, the 
router needs to be
known to the CA when the request is made. So, if the router is 
registered in a database
accessible to the CA, that database should contain the AS # that the 
router is authorized
to represent. Having the router propose an AS# is OK too, but the CA is 
authoritative.

Steve

---

From: Rob Austein <[email-masked]>
Date: Tue, 01 Jul 2014 18:29:48 -0400

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.

---

From: Rob Austein <[email-masked]>
Date: Tue, 01 Jul 2014 18:34:19 -0400

At Mon, 30 Jun 2014 11:27:03 -0400, Stephen Kent wrote:
> 
> I did suggest we might use other cert request mechanisms. EST is the
> obvious, current, standards-based option for this, if folks want to
> consider alternatives to PKCS#10. Since it was authored by a Cisco
> guy, there is some chance it might become available in their
> routers. I would suggest this path only for router certs, not for
> the RPKI certs. That might make it unpalatable, as a CA operated by
> an ISP would have to deal with two cert request formats: PKCS#1- for
> child CA certs (if the ISP is not a stub in the RPKI tree) and EST
> for router certs.

Is there any real benefit to EST, given that we already have to
support PKCS #10 and given that PKCS #10 implementations are almost
certainly easier to find than EST implementations?

Absent some serious advantage that I'm not seeing, this doesn't seem
particularly attractive.

> I'm just pointing out options.

Understood.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Jul 2014 10:00:16 -0400

Rob,

> certainly easier to find than EST implementations?
As I noted, I am aware of only a Cisco implementation, but we could 
check with
Max Pritikin to see if he is aware of others.

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Jul 2014 10:50:27 -0400

> just needs to be fixed, as it violates the base specification.

+1

>  listed in the ASIdentifiers extension.

+1

> 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.

> 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

---

From: Sean Turner <[email-masked]>
Date: Wed, 2 Jul 2014 11:16:39 -0400

On Jul 02, 2014, at 10:00, Stephen Kent <[email-masked]> wrote:

> As I noted, I am aware of only a Cisco implementation, but we could check with

Dan’s got an implementation on github:

https://github.com/danharkins/est

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 30 Jul 2014 14:10:04 -0400

> https://github.com/danharkins/est

Here’s the link for Cisco's:

https://github.com/cisco/libest

spt