Subject: Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

From: "David A. Cooper" <[email-masked]>
Date: Fri, 14 May 2021 09:52:33 -0400

> IANA is asked to establish a registry of signature algorithm values,
> named "CT Signature Algorithms".
>
> The following notes should be added:
>
> *  This is a subset of the TLS SignatureScheme Registry, limited to
>    those algorithms that are appropriate for CT.  A major advantage
>    of this is leveraging the expertise of the TLS working group and
>    its Designated Expert(s).

Sorry if I am late commenting on this issue, but I haven't been 
following this list (or the document) very closely.

While the above policy may be fine at the moment, I am concerned that it 
may be an issue in the future.

The signature algorithms in the NIST Post-Quantum Cryptography 
Standardization 
<https://csrc.nist.gov/Projects/post-quantum-cryptography/round-3-submissions> 
project generally have much larger signatures than the algorithms listed 
in Table 8 of draft-ietf-trans-rfc6962-bis-37. For example smallest 
Falcon signatures are 666 bytes and the smallest CRYSTALS-Dilithium 
signatures are 2420 bytes. Two of the candidate signature algorithms 
have smaller signatures, 33 bytes for GeMSS and 66 bytes for Rainbow, 
but these algorithms have very large public keys, 352.19 KB for GeMSS 
and 101.2 KB for Rainbow. There are, of course, other post-quantum 
signature algorithms that were not submitted to NIST that have small 
signatures sizes, but it is my understanding that they all tend to have 
very large public keys as well.

It is my understanding that for Certificate Transparency signature size 
is very important while public key size isn't, but for TLS client and 
server authentication what's more important is the total size of the 
signature plus the public key. So, when the time comes to select 
post-quantum signature algorithms, it is quite possible that the 
algorithms that are best suited for Certificate Transparency would be 
considered unacceptable for TLS.

I suppose an algorithm could be added to the TLS SignatureScheme 
registry even if it did have one, two, or three hundred KB public keys 
and so was unlikely to ever be used for TLS. However, I just wanted to 
raise a potential issue with limiting Certificate Transparency to only 
using signature schemes approved for use with TLS.

Thanks,

David Cooper

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 15:31:29 +0000

*   I suppose an algorithm could be added to the TLS SignatureScheme registry even if it did have one, two, or three hundred KB public keys and so was unlikely to ever be used for TLS. However, I just wanted to raise a potential issue with limiting Certificate Transparency to only using signature schemes approved for use with TLS.

This is a reasonable point to consider, but as the WG has been in “get this draft published and then close” for a few years now, it’s probably too late.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 May 2021 11:38:09 -0400 (EDT)

On Fri, 14 May 2021, Salz, Rich wrote:

>  *  I suppose an algorithm could be added to the TLS SignatureScheme registry even if it did have one, two, or three hundred KB
>     public keys and so was unlikely to ever be used for TLS. However, I just wanted to raise a potential issue with limiting
>     Certificate Transparency to only using signature schemes approved for use with TLS.
> 

Yes, I don't see this issue as one that would prevent this document from
working. So we are not going to take this up now.

So once this issue comes up in the future, or becomes plausible for
needing a solution, it can be worked on in a new WG.

Paul