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

[Eric Burger <[e-mail]>]

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?

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)?