Re: [stir] STIR certificate delegation

[Chris Wendt <[e-mail]>]

+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=[e-mail]> 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.
> 
> 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,
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir