Thank you for the detailed review! Please see some responses inline below.
-yaroslav On Thu, Jun 19, 2025 at 2:30 AM Eric Rescorla <[email protected]> wrote: > Thank you for posting this. Like Watson, I'm a bit uncertain about the > value proposition of this draft, but for the moment I'm going to put > that aside and offer some small technical comments. > > Key goal of submitting this proposal is to ignite a productive discussion. The way I see it, there are three potential paths TLS could take: - Do not explicitly specify PQ/T when it comes to signatures. Migrate from classical certificate chains directly to pure PQ certificate chains - Specify composite signature schemes as an intermediate step between classical PQ and pure PQ - Use dual certificates to build composition on TLS layer Based on the vast range of TLS use cases I would not be surprised if we end up with a combination of the above. > > S 4.1. > dual_signature_algorithms is used. The signature_algorithms > extension indicates algorithms acceptable for single-certificate > authentication and MUST contain either a non-empty list of such > algorithms or be empty if only dual-certificate authentication is > acceptable. > > I think it would help to make this point clearer. I missed the > first time that this was how you say "I insist on dual-certificate > authentication". > > Fully agree. Current proposal went through quite a few iterations which does not help with overall clarity. Thank you for highlighting this particular issue. > > S 5.1.1. > When parsing DualSignatureSchemeList, implementations MUST NOT make > assumptions about which sub-list a given algorithm will appear in. > For example, an implementation MUST NOT assume that PQ algorithms > will appear in the first list and PQ in the second. As a test, if a > TLS handshake containing a DualSignatureSchemeList succeeds, then an > equivalent TLS handshake containing an equivalent > DualSignatureSchemeList but with the first and second lists swapped > MUST also succeed. However, it is not required that these two test > cases result in the same selected signature algorithm and > certificate. See Appendix C for a suggested configuration mechanism > for selecting a preferred pair of algorithms. > > Would it be legal to supply two lists that have the same > PQ-status? E.g., > > first_signature_algorithms = [ECDSA-P256] > second_signature_algorithms = [Ed25519] > > Yes, the same PQ-status of elements in both lists is legal according to current design. Some may want to allow SLH-DSA or composites roots/intermediates in both chains. > > 5.2. Certificate Message Encoding > Maybe I missed it, but how do I know whether the peer decided > to use dual signatures? Do I just have to look for the null > entry? If not, it seems like it would be better to have > an indication somewhere of what happened. > > > S 5.3. > struct { > SignatureScheme first_algorithm; > opaque first_signature<0..2^16-1>; > SignatureScheme second_algorithm; > opaque second_signature<0..2^16-1>; > } DualCertificateVerify; > > Figure 6: DualCertificateVerify message > > It is an error for any fields to be empty. > > Nit: don't you want to specify a lower bound of 1, then? > > Indeed > > In particular, the > DualCertificateVerify structure MUST NOT be used to carry only a > single signature. Both signatures included in a single > DualCertificateVerify structure MUST use different signature > algorithms. Violation of this rules MUST result in session > termination with an illegal_parameter alert. > > I note that you don't seem to require that the lists be > disjoint above. I.e., you say they are disjoint but there > is no MUST language and no check. > > > As mentioned previously, we want to allow overlap algorithms for root/intermediate certificates. > > > On Wed, Jun 18, 2025 at 5:04 PM Watson Ladd <[email protected]> wrote: > >> On Wed, Jun 18, 2025 at 5:00 PM Yaroslav Rosomakho >> <[email protected]> wrote: >> > >> > Because it won’t require running a zoo of PKIs. Ideally just two - >> classic and pure PQ with eventual convergence on the latter. >> >> Why is it impossible to have a classical and pure PQ PKI, and then >> have clients signal support for which to show, to enable transition? >> This is what we already have, and already has worked. >> >> > >> > -yaroslav >> > >> > On 19 Jun 2025, at 01:51, Blumenthal, Uri - 0553 - MITLL < >> [email protected]> wrote: >> > >> > And you want a composite signature in TLS - why? >> > — >> > Regards, >> > Uri >> > >> > Secure Resilient Systems and Technologies >> > MIT Lincoln Laboratory >> > >> > On Jun 18, 2025, at 19:48, Yaroslav Rosomakho <[email protected]> >> wrote: >> > >> > >> > On Thu, Jun 19, 2025 at 1: 33 AM Watson Ladd <watsonbladd@ gmail. com> >> wrote: On Wed, Jun 18, 2025, 4: 30 PM Yaroslav Rosomakho <yrosomakho@ >> zscaler. com> wrote: One of the key use cases is to simplify PKI >> architectures for closed environments >> > ZjQcmQRYFpfptBannerStart >> > This Message Is From an External Sender >> > This message came from outside the Laboratory. >> > >> > ZjQcmQRYFpfptBannerEnd >> > On Thu, Jun 19, 2025 at 1:33 AM Watson Ladd <[email protected]> >> wrote: >> >> >> >> On Wed, Jun 18, 2025, 4:30 PM Yaroslav Rosomakho < >> [email protected]> wrote: >> >>> >> >>> One of the key use cases is to simplify PKI architectures for closed >> environments that will have to deal with a mix of clients. >> >>> >> >>> Transition from RSA to ECDSA required two end-entity certificates and >> did not have to touch the rest of the certificate chain. >> >> >> >> >> >> Why does this draft make that simpler? >> >> >> >> It envisions two separate chains. Same as with using the existing >> negotiating mechanisms. >> >> >> > >> > With a composite certificate approach two separate chains are >> sufficient only if one serves classic-only clients and composite-only >> clients that are compatible with a given choice of composites. PQ-only >> clients or clients with other opinions about components of PQ/T will >> require an additional chain for every variation. >> > >> > >> > -yaroslav >> > >> > >> > This communication (including any attachments) is intended for the sole >> use of the intended recipient and may contain confidential, non-public, >> and/or privileged material. Use, distribution, or reproduction of this >> communication by unintended recipients is not authorized. If you received >> this communication in error, please immediately notify the sender and then >> delete all copies of this communication from your system. >> > >> > >> > >> > This communication (including any attachments) is intended for the sole >> use of the intended recipient and may contain confidential, non-public, >> and/or privileged material. Use, distribution, or reproduction of this >> communication by unintended recipients is not authorized. If you received >> this communication in error, please immediately notify the sender and then >> delete all copies of this communication from your system. >> >> >> >> -- >> Astra mortemque praestare gradatim >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
