On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: > > > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni <mohit06...@gmail.com> wrote: >> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi <ryan-ietf...@sleevi.com> wrote: >> > >> > >> > >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni <mohit06...@gmail.com> wrote: >> >> >> >> Hi Ryan, >> >> Thanks for answering my question in a lot of detail. I asked this >> >> question in the context of a private PKI for client certificates. You >> >> can assume a scenario where the client certificates are issued to >> >> users/devices in an organization from a self service portal by the >> >> organization's existing private PKI for 1000s of users under different >> >> domains (multiple CAs). >> >> >> >> What I get from your answer is that using CT for client certificates >> >> makes sense when: >> >> >> >> 1) There is an existing private PKI. >> >> 2) There are multiple CAs issuing the client certificates. >> >> 3) The PKI uses non Web PKI (non public) CT log servers and auditors. >> >> >> >> I don't agree with your comment about following the same priority >> >> preferences that exist for server certificates, the [2] and [3] makes >> >> more sense when reversed or kept at an equal priority in the context >> >> of client certificates. Here is my reasoning: >> >> In the server PKI, it is practically easier to make changes in the web >> >> servers to support [2] (i.e. sending the SCT extension by pre >> >> fetching the data from the CA) but it may not be that easier to >> >> implement it on 100s of thousands of client devices. Imagine a large >> >> cell phone manufacturer implementing [2] for all the devices that they >> >> have sold in the last 10 years. >> > >> > >> > Right, I can understand the temptation to consider OCSP Stapling as a more >> > attractive solution, because it relies on the CA taking the requisite >> > action, and thus avoids the need for client implementation, in theory. But >> > the problem is that it's largely "in theory" - that is, robust OCSP >> > stapling is just as hard for clients to implement as obtaining SCTs >> > directly. >> > >> > Nearly 6 years ago, I wrote up [1] to discuss what robust OCSP stapling >> > looks like, from the server side, which captures some of the challenges >> > here. Few servers robustly support this (I believe Microsoft IIS and the >> > Caddy web server are the two notable exceptions), and so the idea of >> > pushing that all to clients is roughly the same challenge as having >> > clients obtain SCTs directly. The main argument for OCSP-embedding over >> > TLS-embedding is not one of simplicity, but of centralized control and >> > communication: the idea being that you can have all your clients contact a >> > single point of contact (the CA's OCSP responder) to obtain the policy. >> > >> > For servers, in the context of the Web PKI, it's quite appealing to swap >> > priority for OCSP-embedding over TLS-embedding because of this. It equally >> > gives Web PKI CT Logs a single point of contact for purposes like rate >> > limiting and abuse detection, which can make it easier to address any >> > concerns. However, in the threat model of "Unreliable CA", where CAs >> > continue to fail to implement CT correctly [2][3], that seems to be >> > missing the operational lessons. Given the assumption that the model here >> > was private PKI with private CT logs, then you're likely better off with a >> > (privately expressed) policy mechanism on the client versus trying to >> > robustly support OCSP stapling on clients, since the failure mode here >> > impacts not only CT, but the revocation processing. >> > >> > [1] https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 >> > [2] https://sslmate.com/blog/post/apples_new_ct_policy >> > [3] >> > https://www.hardenize.com/blog/certificate-transparency-policies-diverge-with-apples-update >> >> I think you misunderstood me, I am not recommending the use of OCSP >> stapling here. I agree with you that the OCSP Stapling is practically >> almost the same as a client fetching the SCT and sending it to the >> server in the TLS stream. I am recommending that the CA/OCSP responder >> can attach SCTs as an OCSP extension along with the revocation status >> of the client certificate in the response to the server's OCSP Request >> and server can verify the certificate based both revocation status and >> the number of SCTs in the OCSP response from the CA/OCSP Responder. I >> know there are issues with how OCSP is implemented by various vendors >> but we can always work on learning from the mistakes and improve OCSP >> to make it more interoperable. > > > In the context of CT implementations, delivering via OCSP means delivering > via OCSP stapling. This is by design - to ensure everything is provided > in-band during connection establishment. > > The server fetching an OCSP response and using the SCTs from that is no > different than if the server simply looked up the certificate in the CT Log’s > entries: it’s an active dependency on a 3P service during connection > establishment, which CT intentionally worked to avoid. > > This is why they’re treated as equivalent: in every CT-verifying > implementation today, OCSP support means stapling.
Thanks for the clarification Ryan, now it all makes a lot of sense. Please excuse my ignorance in this regard. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
