Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
> But I have to say, the core problem this proposal faces would seem to be lack of demand on the part of folks who consume client certificates. Agreed. In our experience, client certs are deployed from an enterprise PKI, and the receiving consumers assume valid issuance. I'm not aware of any of our customers (the few that use client certs) who also use a public CA, or even more than one. Added the trans list. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
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. Thanks, Mohit Server certificate priority list: [1] Ideally, embedded within the (client) certificate itself [2] If not embedded, then included as part of the TLS handshake (which TLS 1.3 makes it possible for clients to send such information, and surely no one would be building new mTLS on TLS 1.2 given the issues with client certs in 1.2) [3] Optionally, embedded in the OCSP response, although virtually no client mTLS implementation supports OCSP stapling correctly, which is also a TLS 1.3 thing On Sun, May 9, 2021 at 3:20 PM Ryan Sleevi wrote: > > > > On Sun, May 9, 2021 at 1:14 PM Mohit Sahni wrote: >> >> Hello TLS WG, >> >> RFC6962 only talks about support of CT to verify the server >> certificates, however while working on zero trust services that >> require MTLS for each connection, I realized that enabling CT for >> client certificates can make the TLS handshakes with Mutual TLS more >> secure. (I don't want to go into details of how CT can make it more >> secure as those benefits are already mentioned in RFC6962). > > > Question: Are you assuming existing Certificate Transparency logs (i.e. for > Web PKI), or are you standing up custom logs? > > I'm not aware of any client implementations that allow custom logs, so I > think it's reasonable to take implicit that you're discussing Web PKI, in > which case, using MTLS like this unquestionably is *less* secure and actively > harmful to security, due to the significant fragility in mTLS (e.g. a lack of > automation on the client side, a lack of robust verification on a server > side). This is why, for example, there have been discussions about forbidding > serverAuth certificates from the Web PKI being used for clientAuth, due to > the associated harms. > > Assuming you are discussing a private PKI, then I would say the > justifications of 6962 are things you can address early on with the PKI > design (i.e. avoiding the multi-party PKI that the Web PKI has). So it should > not be taken for granted that CT is the "right" solution. > > However, going further, and if we assume a private PKI, with a > multi-stakeholder scenario that makes 6962 useful for your case (i.e. > implying the PKI design is already problematic), then there's not a way for > the server to indicate its expectations of the client's certificate being > logged, and this is arguably a feature, not a bug, since "being logged" is a > nonsensical phrase without understanding the server's set of logs. Indeed, > the "right" way to do this is to follow the same priority preferences that > exist for server certificates, namely: > > 1) Ideally, embedded within the (client) certificate itself > 2) If not embedded, then included as part of the TLS handshake (which TLS 1.3 > makes it possible for clients to send such information, and surely no one > would be building new mTLS on TLS 1.2 given the issues with client certs in > 1.2) > 3) Optionally, embedded in the OCSP response, although virtually no client > mTLS implementation supports OCSP stapling correctly, which is also a TLS 1.3 > thing > > However, again, going back to first principles: If your goal is to repurpose > existing PKIs, such as Web PKI, for client certificates, then that's > fundamentally flawed on many levels, and has the risk of creating both > operational issues for you and your clients, and in doing so, creating > security issues for the broader ecosystem of users relying on the Web PKI for > servers. If your goal is to establish a new PKI for such purposes, then there > are plenty of approaches early on in the design that can avoid the set of > considerations that directly lead to CT, and while there's still an indirect > benefit, it may be that you find the sim
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
Hi Melinda and Rich, Thank for your comments, I agree that there is not much demand from the enterprise PKI but with the rise of IOT devices and automatic enrollment for client certificates, a need for some auditing of all the issued client certificates is becoming more important. Managing large services that use client certificates, I feel having some assurance that the clients have SCT logs and are not revoked will give me a better sleep at night. -Mohit On Mon, May 10, 2021 at 6:04 AM Salz, Rich wrote: > > > But I have to say, the core problem this proposal > faces would seem to be lack of demand on the part of folks who > consume client certificates. > > Agreed. In our experience, client certs are deployed from an enterprise PKI, > and the receiving consumers assume valid issuance. I'm not aware of any of > our customers (the few that use client certs) who also use a public CA, or > even more than one. > > Added the trans list. > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Trans] Certificate Transparency for Client certificate in MTLS handshake
> faces would seem to be lack of demand on the part of folks who consume client certificates. > I'm not aware of any of our customers (the few that use client certs) who also use a public CA, or even more than one. With the relatively slow adoption of the EU's eIDAS legislation and thus national PKIs, the demand will probably grow, but within a decade. But it's unlikely that countries themselves will show any interest in participating in this process because the adoption of CT itself is far away. My humble prediction is that in a decade people will finally start using CT in the context of MTLS and find it somehow broken, that is if it's not taken into account right now. On Mon, May 10, 2021 at 4:04 PM Salz, Rich wrote: > > But I have to say, the core problem this proposal > faces would seem to be lack of demand on the part of folks who > consume client certificates. > > Agreed. In our experience, client certs are deployed from an enterprise > PKI, and the receiving consumers assume valid issuance. I'm not aware of > any of our customers (the few that use client certs) who also use a public > CA, or even more than one. > > Added the trans list. > > > ___ > Trans mailing list > tr...@ietf.org > https://www.ietf.org/mailman/listinfo/trans > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 9:43 AM Mohit Sahni 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
Mechanically on the TLS side, we already aligned the client and server certificate flows in TLS 1.3. TLS 1.3 already allows signed_certificate_timestamp in the CertificateRequest message. So basically what you said in Approach 1, except there's no need for the server to condition the CertificateRequest extension on a ClientHello extension. The ClientHello -> (server)Certificate and CertificateRequest -> (client)Certificate flows happen independently. Same with status_request for OCSP. So I don't believe you need any TLS protocol changes here. Of course, that is purely about where to stick the bytes in TLS. Whether and how to use those bytes in your organization's private client-certificate-specific PKI is a more complex question and I'll defer to what others have said on the thread here. On Mon, May 10, 2021 at 11:42 AM Ryan Sleevi wrote: > > > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni 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 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi wrote: > > > > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni 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. Thanks Mohit ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 3:23 PM Mohit Sahni wrote: > On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi > wrote: > > > > > > > > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni > 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. >
Re: [TLS] Certificate Transparency for Client certificate in MTLS handshake
On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi wrote: > > > > On Mon, May 10, 2021 at 3:23 PM Mohit Sahni wrote: >> >> On Mon, May 10, 2021 at 8:41 AM Ryan Sleevi wrote: >> > >> > >> > >> > On Mon, May 10, 2021 at 9:43 AM Mohit Sahni 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 se
