> 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

Reply via email to