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.
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".
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]
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?
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.
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]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
