On Monday, 31 January 2022 21:18:52 CET, Ryan Sleevi wrote:
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
Browsers are the only software that use browser's implementation of
certificate
verification and revocation.
And while they are significant users of TLS, they're definitely not
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote:
>
> Browsers are the only software that use browser's implementation of
> certificate
> verification and revocation.
>
> And while they are significant users of TLS, they're definitely not the
> only important users of TLS.
In the context of
On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote:
On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor
wrote:
This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a
client deliberately fail a connection when the problem might be a flaw
with an unrelated network
> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer wrote:
>
> So our plan moving forward is to essentially keep the new text on OCSP [1]
> and add a reference to RFC 7633 (the certificate must-staple extension). But
> only as a MAY. In addition, we will add a MUST requirement to perform (some
> kind
24 January 2022 at 17:19
To: uta@ietf.org , t...@ietf.org
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor
wrote:
> So, arguably, the advantage of revocation checking via OCSP stapling
> over short-lived certificates today has to do with keeping CT logs a
> manageable size, not with any particular security gain in terms of
> revocation
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived
On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote:
>> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor
>> wrote:
>
>> Do you think that DNSSEC should be soft-fail for CAA checks, or should
>> we urge the CAs to be more strict here? Perhaps that would be another
>> recommendation.
>
> CAA
This discussion seems kind of out of scope for 7525-bis, which is about how
to use TLS, but doesn't seem to say much of anything in terms of how to
operate a CA.
The current draft seems not to say anything about what clients ought to do
and to say that servers SHOULD support OCSP and OCSP
On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote:
> > > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > > we urge the CAs to be more strict here? Perhaps that would be another
> > > recommendation.
> >
> > CAA lookups must not softfail. This needs to be the
On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni
wrote:
> > Do you think that DNSSEC should be soft-fail for CAA checks, or should
> > we urge the CAs to be more strict here? Perhaps that would be another
> > recommendation.
>
> CAA lookups must not softfail. This needs to be the case whether
> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor
> wrote:
>
>> Without wanting to detract too much from the core question of the thread,
>> how does this address the routing gap? The adversary at the routing layer
>> just redirects the host being validated to control the key that way, and
>>
On Fri 2022-01-21 15:23:56 +, Salz, Rich wrote:
> Second, there is the history of poor behavior by some CA's, which
> leads to the primary user agent (browsers, or perhaps TLS runtimes)
> not being able to just completely trust them. Perhaps that historic
> era has passed, and it is time for
>I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.
For that, you mainly want certificate transparency, no?
> If certificate validation is the process of
For additional context, here's s research study we published a few years
back on OCSP must-staple in the Web context:
https://cbw.sh/static/pdf/chung-imc18.pdf
Nick
On Wed, Jan 19, 2022 at 11:58 AM Mohit Sahni wrote:
> Hi,
> > So for the new BCP, we have three options:
> >
> > Add a
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
16 matches
Mail list logo
