sponse to the
server indicating that client has a CT log along with the log. Server
can enforce both CT and Revocation checks at the same time.
Please let me know your opinion on this and do you think there is some
merit to standardize this. Thanks for paying attention to my email.
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
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 se
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 certif
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 Sahn
Internet-draft and get back to the group
soon.
Please feel free to share any other use cases you might have for
validating CT for client certificates in MTLS connections.
Regards,
Mohit
On Mon, May 10, 2021 at 6:55 PM Mohit Sahni wrote:
>
> On Mon, May 10, 2021 at 1:14 PM Ryan Sleevi
ates discoverable via DNS, for MTLS authentication
> and object security use cases. This proposal could make your revocation
> checks easier, and it's more performant than querying a hosted CT log. This
> can also mitigate naming collisions that can occur when you allow multiple
> roots
Just want to highlight one more issue with using the original extension,
many network security devices have threat signatures to identify the
heartbeat extension in packet streams and they will block the sessions that
match the signatures.
On Thu, Oct 21, 2021 at 7:31 AM Hanno Böck wrote:
> On T
Hi,
> So for the new BCP, we have three options:
>
> Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also
> TLS 1.2 implementations) to fail the handshake if the OCSP response is
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
> Remove the whole di
