> On May 28, 2025, at 10:55, Deb Cooley <debcool...@gmail.com> wrote: > > 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 > <mailto:s...@sn3rd.com>> wrote: >> >> >>> On May 27, 2025, at 10:26, Deb Cooley via Datatracker <nore...@ietf.org >>> <mailto: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')
No example envisioned. It was an open ended place holder for future algorithms that might work that way. As far as a comment, when an algorithm is defined then it will say when it is or is not applicable ;) >> 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