Hi Ilari, thanks for your response. A few remarks inline:
On 04/21/2017 12:48 PM, Ilari Liusvaara wrote: > 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). In essence you are doing this through the extension as well just using a different format. > > Defining new extensions is much more deployable, as slow as it is > (AFAICT, no BR changes needed). I hope that this is true since otherwise you have just traded one problem against the other one. > > 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). I didn't got that impression. > >> 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). Isn't this something ACME was trying to solve as well? Ciao Hannes > > > -Ilari >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
