Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11

[Stephen Farrell <[e-mail]>]

On 09/02/2024 21:42, Mike Ounsworth wrote:
> It may well be useful to define a way to get an AND-mode for CMS sigs, sure.
> Doing that without affecting the PKI would seem like a much easier
> proposition. IIRC, there're ways to do countersigs so presumably modifying
> that mechanism to get an AND-mode would be easy enough.
> 
> [[MO]] If someone wants to write an I-D, even Informational, saying how to
> achieve PQ/T hybrids through a CMS counter-signature mechanism, I would
> happily review it.

Actually, is that even needed? A code-signing scheme is maybe
more likely to use multiple CMS blobs and not multiple SignerInfos.
I'm not sure if the msft code signing thing uses CMS but in any
case it does seem to already support a "multiple signers while
verifying all" option today. (See "/all" in [1]) Be great if someone
knows the real details but on the face of it, handling the multiple
signatures at the application layer and not inside one CMS blob would
seem like a pretty good approach.

    [1] 
https://learn.microsoft.com/en-us/dotnet/framework/tools/signtool-exe#sign-command-options

> In terms of answering the question I've asked, that's a bad argument.
> You're saying that composite sigs can work (which I never questioned, I just
> think they're a bad plan) but you're not demonstrating that they're needed.
> 
> [[MO]] I don't want to quibble over an academic definition of the word "need".

When someone throws in the "academic" tag, it's often a sign that
they're not winning an argument:-)

> [[MO]] But the argument sketch is like this: if someone wants to accomplish
> (2) -- and BSI is a concrete example of "someone" -- then we are not aware of
> any way to achieve it with 5208 and 5652 as they are, so we need some sort of
> new mechanism. 

Yet it seems msft's code signing handles it to some extent
today.

> It is a big design space, so there could be solutions other
> than Composites, but A) we postulate that composites are the simplest such
> solution, and B) there are no competing I-Ds, so LAMPS doesn't currently have
> any alternatives in front of it.

I'm not very interested in "competing" I-Ds but rather in the
IETF spending effort on things that better match application
requirements.

>> both
>> for the signatures on binaries, and for the cert hierarchies that back
>> them;
> 
> If there's no need for hybrid sigs in the application, then I don't see how
> there's a need within the PKI. Again, figuring out what the applications need
> seems like a better plan to me.
> 
> [[MO]] This is circular.
> [[MO]] Stavros (representing BSI) has stated that they have application need.
> They are not seeking the IETF's design input on those application needs;
> simply looking for us to provide the necessary certificate formats.
> [[MO]] This argument is going around in circles.

Yes. You've returned to the argument from authority;-)

>> if you don't think that your PKI ecosystem can react quickly enough to
>> news of an algorithmic break, then deploying all your PQ as composites
>> will give you buffer time to react.
> 
> In the code-signing case, if there are certs for the two independent public
> keys, then that's the same, timewise. How would it differ in that scenario?
> 
> [[MO]] I don't understand the question. Where are you getting your AND mode
> from? I am not aware of a way to get AND mode verification logic from a
> 5652-compliant implementation.

Use two CMS blobs if using CMS then the problem goes away and is
a simple bit of verifier application layer logic.

>> Stavros estimated that his > 10^6 user PKI has approx.
>> 10 year lead times for an algorithm replacement.
> 
> It's not clear to me precisely what they mean by 10 years - I could see it
> taking that long to fully change root key algs, but then if I'm reading it
> right BSI wanted some hash-based alg for their new roots. That'd imply the 10
> years to fix my PKI thing isn't really relevant when considering the necessity
> or otherwise of hybrid sig algs.
> 
>> I assume that 10-year
>> estimate comes, in part, from that PKI environment involving many
>> smartcards, airgapped network segments, offline devices, and other "hard to
>> patch" things.
> 
> I'd be interested if someone outlined a scenario involving such things that
> needs hybrid sigs and needs them now. I've not seen anything like any detail
> of such, so far at least.
> 
>> Therefore it seems like a perfect example of "We well not be able to
>> react quickly, therefore we want to hedge our bets with time-buying
>> mechanisms".
>>
>> I will also put forward that this argument applies equally to public
>> and private trust code signing PKIs, with or without good revocation
>> hygiene; even if the CA is good and responsive about publishing
>> revocation information and the regulatory body good about pulling
>> roots from root programs, as required by CA/B, does not mean that
>> clients will be capable of checking it and receiving those updates in a
>> timely manner.
> 
> I don't see how the above touches on hybrid sigs TBH.
> 
> [[MO]] Ok. Then what do you think this touches on?

I don't understand your question. (Maybe my comment wasn't clear
though.) ISTM that questions related to revocation and root store
maintenance don't touch on whether or not hybrid sig algs are needed.

Cheers,
S.

> [[MO]] And please don't say "Some thing that has not been proposed yet, up to
> and including abandoning X.509", because that is not helpful. You're asking
> for concretes. I am also asking for concretes.
> 
> Cheers,
> S.
> 
>>
>> ---
>> Mike Ounsworth
>>
>> -----Original Message-----
>> From: Stephen Farrell <[e-mail]>
>> Sent: Friday, February 9, 2024 1:38 PM
>> To: Hubert Kario <[e-mail]>; Tim Hollebeek
>> <[e-mail]>
>> Cc: Mike Ounsworth <[e-mail]>; Blumenthal, Uri -
>> 0553 - MITLL <[e-mail]>; Kris Kwiatkowski <[e-mail]>;
>> [e-mail]
>> Subject: Re: [lamps] [EXT] [EXTERNAL]
>> draft-ounsworth-pq-composite-sigs-11
>>
>>
>> Hiya,
>>
>> On 09/02/2024 17:05, Hubert Kario wrote:
>>>
>>> For asynchronous protocols (CMS, code signing, etc.) there are much
>>> stronger arguments for hybrid signatures
>>
>> Could someone walk me though a code-signing scenario that needs hybrid
>> signature algs? I can see wanting both kinds of sig, but not why those
>> can't be separate.
>>
>> The model for code signing I'm envisaging is that the to be signed
>> data are manifests, that having multiple sigs on those isn't an issue
>> and that packagers won't stop making packages with purely classic sigs
>> until after we think a CRQC is available to someone. In that case I
>> don't see any benefit in a single hybrid sig vs. two separate sigs.
>>
>> What am I missing?
>>
>> Thanks,
>> S.
>>