Subject: [stir] STIR certificate delegation

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 12 Mar 2019 14:01:17 +0000

Hello,

I've submitted a new draft which takes a first stab at specifying a way to delegate certificates in STIR. This would allow a carrier, say, to delegate to an enterprise authority for one or more telephone numbers so that the enterprise can run its own authentication service and sign calls itself.

https://www.ietf.org/id/draft-peterson-stir-cert-delegation-00.txt

Basically, this document proposes that delegation of STIR certificates rely on something a bit like the RPKI "encompassing" mechanism: that is, rather than having some explicit constraint in a certificate that indicates which names it can delegate to, that instead the TNAuthList is itself the constraint, so that relying parties who receive calls signed by this certificate, as they inspect a certificate chain, verify that each child certificate's scope of TNAuthList authority is encompassed by its parent's. This can be a bit messy when delegating from SPC to TN ranges, but that messiness probably isn’t avoidable.

It also, perhaps controversially, has an optimization that allows certificates that can sign delegate certificate (and thus have their CA boolean set to "true") to actually sign PASSporTs as well.

This document has a few interactions with the ACME mechanisms using the Authority Token for TNAuthLists as well, which we are still ironing out a bit, but which is reflected in those drafts today.

Comments welcome! We should find some time to discuss in Prague.

Jon Peterson
Neustar, Inc,

---

From: Chris Wendt <[email-masked]>
Date: Tue, 12 Mar 2019 10:51:40 -0400

+1

Jon and I have discussed this and it is aligned with what was presented a few weeks ago to the IP-NNI Joint Task Force for delegated certificates and enterprise use cases.  

> On Mar 12, 2019, at 10:01 AM, Peterson, Jon <jon.peterson=[email-masked]> wrote:
> 
> 
> Hello,
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Mary Barnes <[email-masked]>
Date: Tue, 12 Mar 2019 10:11:10 -0500

But, the proposal in IP-NNI has not yet been agreed, so this is not yet a
requirement for SHAKEN.

Regards,
Mary.

On Tue, Mar 12, 2019 at 9:51 AM Chris Wendt <[email-masked]>
wrote:

> +1
>
> Jon and I have discussed this and it is aligned with what was presented a
> few weeks ago to the IP-NNI Joint Task Force for delegated certificates and
> enterprise use cases.
>
> > I've submitted a new draft which takes a first stab at specifying a way
> to delegate certificates in STIR. This would allow a carrier, say, to
> delegate to an enterprise authority for one or more telephone numbers so
> that the enterprise can run its own authentication service and sign calls
> itself.
> >
> > Basically, this document proposes that delegation of STIR certificates
> rely on something a bit like the RPKI "encompassing" mechanism: that is,
> rather than having some explicit constraint in a certificate that indicates
> which names it can delegate to, that instead the TNAuthList is itself the
> constraint, so that relying parties who receive calls signed by this
> certificate, as they inspect a certificate chain, verify that each child
> certificate's scope of TNAuthList authority is encompassed by its parent's.
> This can be a bit messy when delegating from SPC to TN ranges, but that
> messiness probably isn’t avoidable.
> >
> > It also, perhaps controversially, has an optimization that allows
> certificates that can sign delegate certificate (and thus have their CA
> boolean set to "true") to actually sign PASSporTs as well.
> >
> > This document has a few interactions with the ACME mechanisms using the
> Authority Token for TNAuthLists as well, which we are still ironing out a
> bit, but which is reflected in those drafts today.
> >

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2019 15:20:47 -0400

This generally seems like a sane approach.  We should make sure that it's
clear that an RP *always* needs to verify that TNAuthLists scope for STIR
certificates.  That may already be in there, but it wasn't obvious to me on
a quick skim.  In particular, it seems like this doc needs to formally
update RFC 8226.

I would prefer if CA certificates were distinct from PASSporT-signing
certificates, but if it's really not tolerable to have one more hop in the
chain, I can probably live with it.

--RLB

On Tue, Mar 12, 2019 at 10:01 AM Peterson, Jon <jon.peterson=
[email-masked]> wrote:

>
> Hello,
>
> I've submitted a new draft which takes a first stab at specifying a way to
> delegate certificates in STIR. This would allow a carrier, say, to delegate
> to an enterprise authority for one or more telephone numbers so that the
> enterprise can run its own authentication service and sign calls itself.
>