I've read draft-rescorla-tls-subcerts-01 and have a few comments. It's a well written document and the low-level mechanics look ok. However, I think I have a couple of issues with the overall design.
First: it is not self-sufficient. The fact that clients must opt-in implies that servers must have a backup plan. Since keeping the high-value key material in the same node as the delegate credentials contradicts the basic security goal, the only realistic fallback is to have a key-server / LURK box at hand? But this has the known and already discussed limitations -- complicated setup and operations, scaling issues, single point of failure, etc. -- which make it inapplicable to some key use cases (CDN). Second, we need to change the stack at the endpoints. This might be OK for browsers, but it's a bit more problematic when the UA is an STB or a residential gateway, as these things tend to have much slower release and upgrade cycles. With regards to WG adoption, I guess I'm neutral. I think it doesn't hurt to have something like this, but for the reasons stated above, I'm not sure it provides a solution to the LURK problem. Cheers, t PS: It'd be nice if the document discussed the implication of the "unregulated" delegation mechanism especially with regards to its auditability. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
