> On 19 Jun 2025, at 02:03, 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.
> 

It is perfectly possible if you only have clients that require either classical 
or pure PQ signatures. In that case you don’t need dual certificates or 
composite certificates. But clients requiring PQ/T - that is both PQ and 
traditional signature at the same time - would need a separate PKI with 
composite certificates (such as those proposed in 
draft-reddy-tls-composite-mldsa) or dual certificates proposed in this draft.

>> 
>> -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

-- 


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]

Reply via email to