inline w/ [DC]. I'm fine w/ no changes, just pushing a little on your definitions....
Deb On Wed, May 28, 2025 at 10:00 AM Sean Turner <s...@sn3rd.com> wrote: > > > On May 27, 2025, at 10:26, Deb Cooley via Datatracker <nore...@ietf.org> > wrote: > > Deb Cooley has entered the following ballot position for > draft-ietf-tls-rfc8447bis-12: No Objection > > 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Ben Schwartz for their secdir review. > > Section 4: Is there a note to be added to 'connection_id'? (just looks a > little weird to have notes for the other three) > > > So the comment was to have enough info to be able to track why it was > (deprecated). The reference column already refers to RFC9146, which > includes this: > > Although the value 53 had been allocated by early allocation for a > previous version of this document, it is incompatible with this document. > Therefore, the early allocation has been deprecated in favor of this > assignment. > > So, I think it’s clear why it was deprecated. > [DC] this is fine. > > Section 9: Why is 'none' recommended 'Y' (it seems like this should be > D)? > And what is the difference between 'none' and 'intrinsic’? > > > Not much, except that I think if you’re using ed25519 or ed448 you would > use Intrinsic: > > none meaning is: > > The "none" value is provided for future extensibility, in case of a > signature algorithm which does not require hashing before signing. > > [DC] Is there an example envisioned where 'does not require hashing before signing' is not actually the hash is incorporated into the signing algorithm (which is intrinsic apparently)? I guess if the data is short (smaller than the hash output would be). But how likely is that? Is there a comment explaining when this is/isn't applicable? (because it is a 'Y') > > Intrinsic meaning is: > > For bits-on-the-wire compatibility with TLS 1.3, we define a new > dummy value in the "TLS HashAlgorithm" registry that we call > "Intrinsic" (value 8), meaning that hashing is intrinsic to the > signature algorithm. > > > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
