Digicert feedback

[ounsworth]

https://mailarchive.ietf.org/arch/msg/spasm/ReWx7kichMke-HuTHjCih3iZpD0/

DigiCert's CA engineering team has some comments on the open issues related
to the composite-sigs draft. We're going to put them in one email just
because we have comments on quite a few of them.

ISSUE #1
(Github issue: #9)

ASN.1 wrapping confuses people. This came up in the hash-based signatures
updates last call. Nobody knows what ASN.1 is, or what the consequences
of omiting it are (to be clear, there are really none).

We agree that this is largely a question of people being unfamiliar with
ASN.1, and that explanatory text is sufficient. All that is needed is a
clear explanation of example what the BIT STRING is, and explaining that
it's simply the bits of the key itself seems pretty straightforward.

One can then say something similar to:

"In some situations and protocols, the key might be wrapped in ASN.1 or
may have some other additional decoration or encoding. If so, such wrapping
MUST be removed prior to encoding the key itself as a BIT STRING."

Hopefully that makes things crystal clear.

ISSUE #2
(Github Issue: #19)

We don't think it's worth the extra complexity and expense of an additional
hash operation just to achieve a fixed size output. The variation in size
is already pretty small.

ISSUE #3
(Github issue: #6)

Again, we don't believe the additional complexity is worth it for a pretty
trivial improvement in the private key size. But it's not a strong opinion,
we could go either way.

Open Issues affect both Composite Signatures and Composite KEM:
ISSUE #4

Chair hat off, I and the CA team are concerned about the slow progress of
the composite signature work. In particular, tying it to the Composite KEM
draft and waiting for the CFRG work on KEM Combiners seems like an
absolutely horrible idea to us. We would like to see Composite Signatures
progress ASAP.

ISSUE #5
(Github issues:
lamps-wg/draft-composite-kem#37
#24
#23)

This is a fun one, and we've spent quite a bit of time discussing it
internally.

In particular, we're still debating the question about exactly how many
backwards compatibility options are really necessary. For example, given
that you already need to add lattice, is it really necessary to allow
PKCS15 to continue to exist? For RSA, there's the reasonable argument that
that might be all you have in your validated hardware/software, but if you
have RSA as a primitive, can't you do PSS instead of PKCS15? Remember, you
already have to make changes on both the signing and verify side anyway.

We're trending in the direction of thinking that the primary decision is
the security level and post-quantum algorithm, and the classical side is
just determined by what "makes sense" for that security level and algorithm.

So what you really want is something like "id-SL1-MLKEM-RSA" where the
document specifies exactly what "RSA" means in the context of a SL1 MLKEM512
composite, e.g. RSA4096-PSS-SHA512. This basically means striving for
at most one combination for each triple of (security level, PQC flavor, classical
flavor) and eliminating unnecessary complexity and diversity of options in what
is essentially a redundancy/backup mechanism.

The basic idea is to more aggressively standardize the backwards
compatibility options to only what's actually necessary, instead of
trying to be backwards compatible with the universe of current behavior,
which both unnecessarily complicates things, and preserves some practices
(e.g. PKCS15) longer than is perhaps prudent.

-Tim