Subscriber-level delegation

[davidben]

(Filing this mostly to capture vague thoughts. Yet another angle in this vast design space.)

Over in #10 (CC @bemasc), I asserted that we didn't need delegation in Merkle Tree certificates because they don't make sense when you assume an up-to-date RP anyway.

Talking with folks at IETF, someone (I forget who... was it you, @bwesterb?) brought up that a subscriber might want to do delegation. E.g. the CA checks you're authoritative *.example.com, but the subscriber wants to mint credentials on demand for abcdef.example.com.

I think the way to think about that apparent contradiction is that CA-level delegation doesn't make sense with up-to-date RPs, but subscriber-level delegation can still make sense. That said, the tradeoffs for such delegation are harsher in a PQ world with large signatures. So I suspect this use case will be much less applicable in the future. But perhaps there are deployments where it's still worth the extra signature.

Supposing that's the case and we want to support it, one answer is to go back to a generic chaining mechanism like X.509, but another answer is to separate the two, a la TLS delegated credentials. I kinda like the latter, actually. As an RP, we already think the two cases have very different requirements. Existing CA policies often distinguish cross-signs from technically-constrained CAs. If we want to capture that, one model would be basically TLS DCs, where we have a tls_delegated_credential_signer (or whatever) SubjectType and some place to inject the DC. Possibly amended to allow refining the name set in the DC, I dunno.

[bwesterb]

I forget who... was it you, @bwesterb?

It might've been @galadran? Anyway, I do agree.