Hi,
I have a layman doubt.
While working on a project, recently I discovered a list of CA cert which
got expired. I am not responsible for sites using those cert. But my end
users said sites using those certs are failing due to expired cert. So I
visited the official CA website to download the
Hi,
Since the draft has DHE cipher suites as a MUST NOT, I believe the
appropriate value is indeed "Discouraged".
(From 8447bis: "N: Indicates that the item has not been evaluated by the
IETF and that the IETF has made no statement about the suitability of the
associated mechanism." That seems inc
>
> The draft draft-tls-westerbaan-xyber768d00-00 references
> draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes,
> since fixed in editor's copy.
>
> And then, the correct reference for X25519 is probably RFC7748 instead
> of RFC8037...
>
>
> Really quick and dirty way to fix thi
Regarding additional key agreements.
For the (public) web it would be best if we can agree on a default key
agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768,
then clients will either HRR half the time or need to send both. Neither
are ideal.
Obviously this point is moot fo
Hi Bas,
I prefer for the MTI to be P-256+Kyber768 for compliance reasons.
It would be trivial for servers to add support for both identifiers as they
introduce Kyber768, but you are right, the new draft should include an MTI
identifier.
From: TLS On Behalf Of Bas Westerbaan
Sent: Friday, Mar
> On 1 Apr 2023, at 09:04, Bas Westerbaan
> wrote:
>
> What about specifying further preliminary key agreements in yet again a
> separate draft?
Agreed. I'll do that.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> I would pair secp384r1 with Kyber768 for completely different reasons:
> Kyber768 is what the team kyber recommends.
Agreed.
> I don't think there are very good reasons for NIST curves here outside
> wanting CNSA1 compliance, and for that you need secp384r1 classical
> part. And for that, I woul
