Re: [stir] Thoughts on draft-ietf-stir-cert-delegation-00

["Peterson, Jon" <[e-mail]>]

Thanks for the notes Eric,

Section 4:
Will SHAKEN certificates carry a TNAuthList? If not, we are in academic exercise land. If so, we are good. If not, should we be? If we should, is it practical?

My understanding is that SHAKEN uses RFC8226 certificates, and RFC8226 certificates contain an object called a “TNAuthList”, which may be populated by SPCs, TNs, or both. So strictly, I think the answer to your question is yes. But more to the point…

The last three paragraphs imply to me that this is a fancy way of saying in the U.S. context the PA will allow the CA to issue signing certificates to enterprises. Is this interpretation correct?

We’re just doing the low-level protocol plumbing here, but that is certainly a way that SHAKEN could adopt this tool. The main SHAKEN design choice there is whether it is up to carriers or the PA to authorize delegation.

If so, does that not dramatically simplify things? An enterprise gets a signing certificate. They sign their Identity header. Since they are not a CSP entitled to put traffic on the public network, their CSP will also sign with something like the opt mechanism. Mission accomplished?

Sure, I’ve heard it suggested that in SHAKEN environments the outbound CSP would add its own “B” attestation Identity header for traceback purposes or what have you.

Remember, a B attestation from a trusted CSP over a signed Identity is going to get much better treatment than an A attestation from The Grace L. Ferguson Robocalling and Storm Door Company<https://www.amazon.com/Grace-Ferguson-Airline-Storm-Hungry/dp/B00122NVAQ>.

Section 5:
Is the verification of the scope of the validation certificate in real-time, or can it be done administratively off-line?

Really this is the subject of the very last paragraph of 4.1. I do think it’s possible to make scope validation a largely offline process, and it’s probably undesirable to require the verification service to have to do network dips related to scope validations in real time while it’s trying to figure out if it wants to alert a the called party. I also think there’s value in being able to audit delegate certificates offline by inspecting a certificate repository. There could be operating environments where scope validation could be combined with some other dip done at the terminating side, though, where the cost wouldn’t be onerous.

Section 8, last paragraph of p. 7:
I thought RFC 2119 does not apply to non-protocol thingies, like being the protocol police and attempting to enforce a totally non-protocol policy. As such, having an RFC 3514 evil bit in the CA seems a bit odd. As the TBD offers, I’d suggest not going there.

Yeah, as the TBD suggests, I’m not entirely sold on that idea – but in a SHAKEN-like environment, where a policy function oversees CA practices to a degree that might actually constitute protocol policing, I might think this is a more realistic approach than usual.

Jon Peterson
Neustar, Inc.