Eric Rescorla writes:
> In this context I generally agree that "application profile" refers to
> an IETF standards track document describing the use of TLS with some
> other protocol.
You're covering the words "application" and "standard", but there's a
further restriction from the word "profile", which (in a technical
context) refers specifically to _narrowing_ the allowed options.
I haven't found any IETF documents telling the reader what the word
"profile" means, but looking around more widely I find definitions in
https://www.etsi.org/deliver/etsi_i_ets/300400_300499/300406/01_60/ets_300406e01p.pdf
that match exactly my understanding of the word: "A base specification
is defined by opposition to a Profile, which constrains optionalities in
one or several base specifications." See the word "constrains"?
For example, for TLS 1.3, a "profile" could prohibit X25519 (and X25519
was ~0% of TLS key exchanges when RFC 8446 was written, unlike today's
~90%), but it can't change the requirement to implement P-256.
I've pointed out in the TLS WG that it would be good to move towards
fully eliminating P-256 (by first mandating X25519, then waiting for
more rollout to ensure interoperability, then deprecating P-256). Could
I just go to some random tiny WG instead and fund people there to issue
an "application profile standard" that replaces the P-256 requirement
with an X25519 requirement? The word "profile" says no. A "profile" can
only _narrow_ options.
As another example, following the HTTP/2 "SHOULD NOT" that you quoted is
in violation of the TLS 1.2 _standard_. The people who wrote this HTTP/2
"SHOULD NOT" screwed up in not going through proper procedures to update
TLS 1.2 for a different MTI---and I'm not actually sure they would have
reached TLS WG consensus for that! There was WG consensus to require ECC
in TLS 1.3; my impression is that part of what created this consensus
was that requiring ECC was specifically for TLS 1.3, while TLS 1.2
implementors weren't forced to change anything.
---D. J. Bernstein
===== NOTICES =====
This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
