Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
draft-ietf-tls-tls13-pkcs1-07

Yes

Deb Cooley
(Paul Wouters)

No Objection

Andy Newton
Éric Vyncke
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Roman Danyliw
(Erik Kline)

Note: This ballot was opened for revision 06 and is now closed.

Deb Cooley
Yes
Comment (2025-10-20 for -06) Sent 
Thanks to Rifaat Shekh-Yusef for their secdir review. 

This specification needs to be PS so that TLS server implementations will modify their TLS offerings where client authentication is necessary.  The same situation is true for 'N' vs 'D'.

This specification allow clients using hardware storage devices (TPMs, Secure Elements, etc.) to migrate to TLS 1.3. 

I support those positions.
Andy Newton
No Objection
Éric Vyncke
No Objection
Gorry Fairhurst
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mahesh Jethanandani
No Objection
Mike Bishop
No Objection
Comment (2025-10-21 for -06) Sent 
I've previously reviewed this document, and the changes are minor. It looks like a solid solution for these devices. I believe "N" is an appropriate value since that indicates the value "either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases" -- this document clearly describes why, despite having IETF consensus, it falls into the latter two buckets.

However, it does seem clear that this document modifies restrictions in RFC8446(bis). While it defines new codepoints with differing behavior for the SignatureScheme enum and thus isn't changing the definition of those codepoints, it is modifying the requirement in CertificateVerify handling that `RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms".`
Mohamed Boucadair
(was Discuss) No Objection
Comment (2025-11-20 for -06) Sent 
Hi David and Andrei, 

Thank you for the effort put into this specification. 

I'm clearing my DISCUSS assuming that https://github.com/tlswg/tls13-spec/pull/1399/files change will be implemented during AUTH48 of draft-ietf-tls-rfc8446bis.

==Inherited from the COMMENTs in my previous ballot, fwiw===

# FIPS 186-4

## Please add a reference

## s/with FIPS 186-4/with US FIPS 186-4

# TLS Registries

CURRENT:
   IANA is requested to create the following entries in the TLS
   SignatureScheme registry, defined in [RFC8446].   

Isn’t draft-ietf-tls-rfc8447bis authoritative here for registry matters? I would replace the 8446 citation with draft-ietf-tls-rfc8447bis.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/tls/dimNOvXqeIaYflBK7s51J43p80U/
Roman Danyliw
No Objection
Paul Wouters Former IESG member
Yes
Yes (for -06) Unknown 

                            

                        
                    

                
            
        
            
                
            
                
            
                
            
                
            
                
            
                
            
                
            
                
            
                
            
                
            
                
                    

                        

                            Erik Kline Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (for -06)
                                
                                
                                    
                                         Not sent