On 27.11.25 17:02, John Mattsson wrote:
Thanks John for writing a separate email. I couldn't follow all these lengthy discussions.Eric Rescorla wrote: > What's *not* compliant is if you have an implementation which doesn't > support P-256, no matter what other groups it supports.As I wrote in my response to Bernstein,
RFC 8446 mandates ECC only when no application profile specifies otherwise.
Looking at starting text of section 9.1, you are right. I guess Ekr's implicit assumption for simplicity was that such an "application profile standard" does not exist for that specific discussion.
But this raises a new question in my mind: RFC8446bis-14 uses 2x "application profile standard" and 2x "application profile" but I don't find any definition of that. I am curious who is the /authority/ for such "application profile standards". You mention CNSA 1.0, CNSA 2.0 and 3GPP TLS profile, which make sense to me. But you also mention:
> Constrained devices, for example, often support only one of secp256r1 or X25519.
which confuses me. Do we have an exhaustive list of application profile standards? If any one can write such profiles, then the whole idea of MTI becomes questionable to me. That is, I could write my own profile and say I am still compliant with RFC 8446.
I am in no position to judge your points. But I really hope the WG can agree on at least some of that to be added in motivation.Muhammad Usama Sardar wrote:>couple of sentences that basically tell me nothing about why this draft even exists. >Specifically, I would like to know more about those users to be able to reach out to them to ask whether they also want attestation.I agree that the draft should include a more detailed motivation. Some relevant points: [...]
- Several countries are recommending or requiring standalone ML-KEM. They may be worth contacting to determine whether they are also interested in attestation.
Thanks very much for the links.I will appreciate if at least one of those which explicitly mentions MLKEM was added in motivation section of the draft.
(That said, my support of publication is still conditioned on that the text in Section 5.1 is completely rewritten or removed)
Is it this one? [0] I have no opinion from PQ perspective but from traditional crypto perspective, I agree with your concern on key reuse. Intuitively, I would assume the same problems would hold in pure PQ but there may be subtleties.
-Usama [0] https://mailarchive.ietf.org/arch/msg/tls/Wc0tnrJX0AwMnjBspeM3pxCwEoU/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
