[lamps] Re: Composite Signatures and KEM open issues that need feedback

[Carl Wallace <[e-mail]>]

Inline…

 

From: Tim Hollebeek <tim.hollebeek=[e-mail]>
Date: Friday, August 16, 2024 at 1:20 PM
To: John Gray <John.Gray=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [lamps] Re: Composite Signatures and KEM open issues that need feedback

 

 

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:  https://github.com/lamps-wg/draft-composite-sigs/issues/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.

 

[CW] Just to highlight one point relative to issue 1. Re: ENCODED BY vs explanatory text, I agree explanatory text is fine if there is not attempt to use CONTAINING. The id-raw-key suggestion was a replacement for use of CONTAINING. Simply providing explanatory text for the non-ASN.1 encoded key seems fine to me, provided the more complicated embedded SEQUENCE is dropped (as it should be for several reasons that were previously enumerated).  Unfortunately, the current ASN.1 definitions in the editor’s copy still lean on an embedded SEQUENCE that attempts to use CONTAINING for non-ASN.1 encoded data, so explanatory text alone doesn’t quite make it without other changes to the definitions.

 

<snip>