Re: [stir] Comments and Ready for Adoption: draft-peterson-stir-cert-delegation

One point inline below...

On Fri, Apr 19, 2019 at 3:37 PM Eric Burger <eburger@standardstrack.com>
wrote:

> High level: it is ready for adoption as a work group item.
>
> Since it will need at least a name change, here are my comments at this
> point in its lifecycle.
>
>
> Section 3.1 says that a certificate path /should/ be validated. Under what
> circumstances would it be OK to not validate the chain?
>
> Section 4: an example chain, or at least a picture, would help
>
> Section 5: Does this mean that all certificates will have “ca” set? If so,
> would we not have to validate the entire chain? I.e., MUST in Section 3.1?
> If not, what stops a bad actor from generating a signing certificate for
> TNs it does not own?
>

Yes, lots of certificates will have the CA bit set.  That's just the PKI's
way of saying, "The holder of this certificate can delegate further".

Recall that there's a difference between a CA and a trust anchor.  Anyone
can be a CA and issue certificates, but the verifier should have a limited
set of CAs it will trust.  Then when you're presented a certificate, the
verification you need to do is that there's a way to chain from that
certificate to one of your trust anchors.

There is a somewhat intersting question around trust anchor configuration
here.  You probably never want to have a TA like you do in the Web PKI that
can vouch for any resources.  So we will want to have RPs scope TAs so that
they can only issue for some set of TNs.  For example, you might have a
national TN that is scoped to its country code.

The same problem arises in the RPKI with regard to IP addresses and AS
numbers, and there was a lot of wrangling since it's not clear what control
/ ownership structure you should align the PKI with there.  I'm pretty sure
there is some solution there, but unfortunately I've forgotten the details.

--Richard

>
> Section 7:
> I’d just refer to STIR’s text with respect there is no anonymity except
> for explicit anonymity (RFC 3325). However, if we have a delegated
> certificate chain, is there an issue with some information leakage? I would
> think not, because would one only use the delegation mechanism when one is
> explicitly NOT trying to be anonymous? I.e., use an asserted identity that
> may not be obvious to the connected service provider (in the SHAKEN sense)?
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>