On Tue, Apr 30, 2024 at 6:17 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:
> but you could just as easily do this with a simple extension from the
> private range, so I'm not sure that was a big blocker.
>
No need for a new extension: a government can use a specific signature
algorith
Hi Brendan, Bas,
On 30/04/2024 05:17, Brendan McMillion wrote:
It seems like, with or without this extension, the path is still the
same: you'd need to force a browser to ship with a government-issued
CA installed. Nothing about this makes that easier. It /is/ somewhat
nice to already have a w
On Tue, 30 Apr 2024 at 03:20, Dennis Jackson
wrote:
>
> When this work was presented at IETF 118 in November, several participants
> (including myself, Stephen Farrell and Nicola Tuveri) came to the mic to
> highlight that this draft's mechanism comes with a serious potential for
> abuse by gov
>
> Of course this is possible in theory, there are no standards police, but
> this argument overlooks the gargantuan technical and economic costs of
> deploying this kind of private extension. You'd need to convince a diverse
> population of implementers on both the client and server side to adopt
On Tue, Apr 30, 2024 at 8:14 AM Brendan McMillion <
brendanmcmill...@gmail.com> wrote:
> Of course this is possible in theory, there are no standards police, but
>> this argument overlooks the gargantuan technical and economic costs of
>> deploying this kind of private extension. You'd need to con
On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla wrote:
>
>
> On the narrow point of shorter lifetimes, I don't think the right way to
> advertise that you have an accurate clock is to advertise that you support
> some set of root certificates.
>
> If we want to say that, we should have an extensio
On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd wrote:
> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla wrote:
> >
> >
> > On the narrow point of shorter lifetimes, I don't think the right way to
> advertise that you have an accurate clock is to advertise that you support
> some set of root certifica
On 30/04/2024 16:13, Brendan McMillion wrote:
Of course this is possible in theory, there are no standards
police, but this argument overlooks the gargantuan technical and
economic costs of deploying this kind of private extension. You'd
need to convince a diverse population of i
As mentioned above, we have such an extension already insofar as
indicating support for Delegated Credentials means indicating a desire
for a very short credential lifetime and an acceptance of the clock skew
risks.
Given how little use its seen, I don't know that its a good motivation
for Tr
On Tue, Apr 30, 2024 at 8:37 AM Dennis Jackson wrote:
> As mentioned above, we have such an extension already insofar as
> indicating support for Delegated Credentials means indicating a desire for
> a very short credential lifetime and an acceptance of the clock skew risks.
>
I agree that DC imp
Reviewer: Tim Chown
Review result: Not Ready
Hi,
I have reviewed this document as an early Operations Directorate review.
The document defines a well-known URI that can be used to inform an
authoritative DNS server of an origin's service bindings, for cases where an
API to perform the function i
Hiya,
Having read the draft and the recent emails, I fully agree with
Dennis' criticisms of this approach. I think this is one that'd
best be filed under "good try, but too many downsides" and left
at that.
Cheers,
S.
On 30/04/2024 00:20, Dennis Jackson wrote:
When this work was presented at I
>
> This doesn't apply in case we're distrusting a CA because it's failed. In
> 9.1 we're rotating keys. As I laid out in my initial mail, we can already
> sign the new root with the old root to enable rotation. There's no size
> impact to up-to-date clients using intermediate suppression or abridg
Hi all. Thanks for the discussion! While we're digesting it all, one quick
comment regarding the feedback in Prague:
>From talking with folks at the meeting, it seemed part of this was due to a
misunderstanding. Trust expressions are not intended to capture per-user
customizations to root stores,
On 30/04/2024 22:33, Brendan McMillion wrote:
This doesn't apply in case we're distrusting a CA because it's
failed. In 9.1 we're rotating keys. As I laid out in my initial
mail, we can already sign the new root with the old root to enable
rotation. There's no size impact to up-t
Thanks Tim,
I'll take your review as confirming the others then and
will work on addressing those issues next week or two.
Cheers,
S.
On 30/04/2024 17:07, Tim Chown via Datatracker wrote:
Reviewer: Tim Chown
Review result: Not Ready
Hi,
I have reviewed this document as an early Operations D
On Tue, Apr 30, 2024 at 3:26 PM Dennis Jackson
wrote:
>
> Let's assuming for a moment we could a) get most of the world to use ACME (a
> worthy but challenging goal) and b) get them to configure multiple CAs and
> receive multiple certificates. We don't need trust expressions to be able to
> d
On 01/05/2024 00:07, Watson Ladd wrote:
On Tue, Apr 30, 2024 at 3:26 PM Dennis Jackson
wrote:
Let's assuming for a moment we could a) get most of the world to use ACME (a
worthy but challenging goal) and b) get them to configure multiple CAs and
receive multiple certificates. We don't need
On Tue, Apr 30, 2024 at 4:30 PM Dennis Jackson wrote:
> On 01/05/2024 00:07, Watson Ladd wrote:
>
> On Tue, Apr 30, 2024 at 3:26 PM Dennis
> Jackson
> wrote:
>
>
> Let's assuming for a moment we could a) get most of the world to use ACME (a
> worthy but challenging goal) and b) get them to c
Internet-Draft draft-ietf-tls-rfc8447bis-09.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.
Title: IANA Registry Updates for TLS and DTLS
Authors: Joe Salowey
Sean Turner
Name:draft-ietf-tls-rfc8447bis-09.txt
Pages: 18
20 matches
Mail list logo
