On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote: > I read through draft-rescorla-tls-subcerts-01 and I ran into some basic > questions. > > I have been wondering why the TLS server operator obtains an end-entity > certificate from a CA (which cannot be used to sign further > certificates) instead of running an intermediate CA him-/herself > instead. This would work without requiring any changes to the client > side. The proposed solution, although technically feasible, will > unfortunately take a long time to deploy since it requires cooperation > from clients, servers, and also from CAs.
There is enormous amount of red tape obtaining intermediates, even technically constrained ones. And as consequence, it is enormously expensive (through not nearly as expensive as public CA). Defining new extensions is much more deployable, as slow as it is (AFAICT, no BR changes needed). Regarding clients, I think the draft specifies LURK as backup plan for clients that don't support subcerts (which causes some extra latency if triggered). > What is also not clear to my why some of the certificate management > protocols, which provide the necessary level of automation, cannot be > used with CAs to request short-lived certificates. AFAIK, that would cause issues with CT and OCSP signing. The latter would be fixable by reintroducing CABForum ballot 153 and passing it (the reasons 153 failed were obviously political instead of technical). -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
