[TLS] TLS Suite Naming Conventions

TLS? Should we recommend against fully specifying things, and argue that negotiation should be for keys, not algorithms, and keys can choose to restrict to achieve full specification? Should we recommend fully specifying things, and then decide if redundant code

Re: [TLS] TLS Suite Naming Conventions

gorithm registry, those are could have > been prefixed with "eddsa". > Sounds like TLS 1.3 aligns with JOSE, and not with COSE Your signature algorithms are "fully specified". Sounds like the "EdDSA'' algorithm as used in JOSE and COSE does not alig

Re: [TLS] TLS Suite Naming Conventions

turns out we need to replace the hash >> function in Ed25519, or change EdDSA, we would not use the same keys. We >> would simply define a new signature scheme, with a different name, and say >> that this is a completely disjoint key type. So, to your original question, >>

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > -- > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > sschm...@google.com > > ___ > CFRG mailing list > c...@irtf.org > https://mailman.ir

Re: [TLS] Trust Expressions Follow-up

gt; CAs, but this is a partial solution at best. Without negotiation, this >>> still means sending certificates for the lowest common denominator to all >>> clients. This wastes bandwidth, particularly with post-quantum >>> cryptography, where every signature costs kilobytes.

Re: [TLS] Trust Expressions Follow-up

certificate", using a SCITT transparency service, since a SCITT receipt is logically an inclusion proof for a single certificate, A "signed feed of receipts" can be thought of as an intermediate data structure for Merkle tree certs... possibly... I need more time to digest the draft.

Re: [TLS] ML-KEM key agreement for TLS 1.3

Does the argument about hybrid code points first generalize to all PQ Code points? Is it equally true of hybrid signatures? I don't understand why registering composite components first wouldn't be assumed. Isn't support for the component mandatory to support the hybrid anyway? Let's assume CRQ

[TLS] Orie Steele's Yes on draft-ietf-tls-tls12-frozen-07: (with COMMENT)

Orie Steele has entered the following ballot position for draft-ietf-tls-tls12-frozen-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https