Personally, I am against any practical use of McEliece given all the other
available options. 1MB public keys are unnecessary, impact performance, and are
wasteful.
Regardless of the public key in the cert though, RFC7924 allows (with other
caveats) for not sending the server cert (and public
Thanks Chris,
I've checked the errata and it is correct. I've marked it as Verified.
Paul
On Tue, Oct 10, 2023 at 8:11 PM Chris Smiley wrote:
>
> H Paul,
>
> We are unable to verify this erratum that the submitter marked as
> editorial.
> Please note that we have changed the “Type” of the
The following errata report has been verified for RFC5054,
"Using the Secure Remote Password (SRP) Protocol for TLS Authentication".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7538
--
H Paul,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata
report to “Technical”. As Stream Approver, please review and set the
Status and Type accordingly (see the definitions at
Dennis:
>> If we are going to allow a certificate to include pointers to externally
>> stored public keys, I think a solution that works for the Web PKI and other
>> PKI environment as well.
>
> I'm trying to understand the use case of certificates with pointers to
> externally stored public
On 10/10/2023 17:53, Russ Housley wrote:
Dennis:
If we are going to allow a certificate to include pointers to
externally stored public keys, I think a solution that works for the
Web PKI and other PKI environment as well.
I'm trying to understand the use case of certificates with pointers
> But if we can at least make it secure, that gives us a bit more breathing
> room in case anyone needs it.
>
For those who missed it: we need it for Edge -> Origin connections, as some
origins do break on split ClientHello. (See e-mail sept 29th.)
___
On Tue, Oct 10, 2023 at 1:24 PM Bas Westerbaan wrote:
> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
>> just let them break in case (a), and then maybe try again with (b), that
>> opens up a downgrade attack. Intermediaries can observe the size of the
>> Client Hello
>
> OK, I see. It's worse than a compatibility risk, though, isn't it? If you
> just let them break in case (a), and then maybe try again with (b), that
> opens up a downgrade attack. Intermediaries can observe the size of the
> Client Hello and make it break
>
Exactly.
On Tue, Oct 10, 2023 at 10:01 AM David Benjamin
wrote:
> On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote:
>
>> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin
>> wrote:
>>
>>> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson >> 40dennis-jackson...@dmarc.ietf.org> wrote:
>>>
To make sure
On Tue, Oct 10, 2023 at 12:42 PM Rob Sayre wrote:
> On Tue, Oct 10, 2023 at 8:28 AM David Benjamin
> wrote:
>
>> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson > 40dennis-jackson...@dmarc.ietf.org> wrote:
>>
>>> To make sure I've understood correctly, we're trying to solve three
>>> problems:
Dennis:
If we are going to allow a certificate to include pointers to externally stored
public keys, I think a solution that works for the Web PKI and other PKI
environment as well. I would not object to the use of abridged certs as an
option, but I would object if it is the only option.
On Tue, Oct 10, 2023 at 8:28 AM David Benjamin
wrote:
> On Tue, Oct 10, 2023 at 6:06 AM Dennis Jackson 40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> To make sure I've understood correctly, we're trying to solve three
>> problems:
>>
>>- Some servers don't tolerate large Client Hellos
>>
Hi Mike,
On 30/09/2023 23:19, Mike Ounsworth wrote:
Consider the following two potential use-cases:
1. Browsers
Browsers already have mechanisms to cache intermediate CA
certificates. It does not seem like a big leap to also cache external
public keys for the server certs of
14 matches
Mail list logo
