Re: [lamps] Key usages for composite keys

I think worrying about intersections and individual components of keys and
whatnot are really a consequence of two bad habits around key management
and generic combinators:

1. We should think of RSASSA-PSS-SHA256-ML-DSA-65 as a single signature
scheme. It happens to be made up of two parts internally, but this is just
an implementation detail. Just as ML-DSA-65 happens to use SHA-3 under the
hood, but that is just an implementation detail of ML-DSA-65.

2. We should drop this notion of a single key type being good for multiple
signature schemes, to say nothing of multiple kinds of algorithms
altogether. The way RSA was defined is a historical quirk, which led to
endless complexity and cross-protocol problems. You start with the
signature scheme, and the signature scheme defines objects, like keys,
*specific to that signature scheme*. We should never have had RSA keys but
RSASSA-PSS-SHA256 keys. Being able to change the hash without changing the
key was a convenient crutch, but we would have been on much more solid
ground, and gotten somewhere more robust, had we put that effort into being
better at cycling the keys themselves.

It's too late now for RSA. Those decisions were made and these bad habits
tend to compound. (X.509's SPKI formats end in other protocols and even
influence the shapes of cryptographic APIs.) But we should not extend these
habits into the future.

Once you correct these bad habits, all these questions become implicit.
There is no difference between key type and key use. The composite
algorithm is just an algorithm and you never use the component keys
separately. The signing function then actually matches the mathematical
definition and simply takes a key and an input; not a key, an input, a hash
function, an MGF function, a salt length, and a PQ composition variant.

Not to say we shouldn't clarify things explicitly, because the X.509 world
is full of these bad habits, but we should consistently phrase such things
with the bad habits corrected. That's the best shot we have to stop
perpetuating them.

David

On Fri, Feb 9, 2024, 13:58 Tim Hollebeek <tim.hollebeek=
40digicert.com@dmarc.ietf.org> wrote:

> I think that’s right, but I didn’t see it written down anywhere, though
> Mike did point out the spot that I missed where it is said implicitly …
>
>
>
> -Tim
>
>
>
> *From:* Russ Housley <housley@vigilsec.com>
> *Sent:* Friday, February 9, 2024 1:57 PM
> *To:* Tim Hollebeek <tim.hollebeek@digicert.com>
> *Cc:* SPASM <spasm@ietf.org>
> *Subject:* Re: [lamps] Key usages for composite keys
>
>
>
> Tim:
>
>
>
> I thought that we already agreed that an RSA key that is used as part of a
> composite MUST only be used for that one purpose.  So, if it is part of
> composite-sig, then it MUST oly be used for a signature operation.
>
>
>
> Russ
>
>
>
>
>
> On Feb 9, 2024, at 11:02 AM, Tim Hollebeek <
> tim.hollebeek=40digicert.com@dmarc.ietf.org> wrote:
>
>
>
>
>
> Hello,
>
>
>
> This is a little off topic and possibly getting ahead of things a little
> bit, but it came up in a discussion with our engineers so I thought I’d
> float it here.
>
>
>
> It’s possible some of this might fit in somewhere in the composite
> signature draft, and if the authors agree and can find an appropriate spot
> for it I’ll draft some text.
>
> Otherwise maybe it goes in “PQC for Engineers” or one of the other PQUIP
> drafts.
>
>
>
> It’s a pretty simple point, but it’s not documented anywhere and it should
> be:
>
>
>
> RSA can be used for both signing and key encapsulation.
>
> ML-DSA can be used for signing.
>
> Composite<RSA, ML-DSA> can be used for … ?
>
>
>
> It’s pretty obvious that a composite key can only do what each individual
> component key can do, so the key usage is at most the intersection of the
> valid key usages of the component keys.
>
>
>
> So the correct answer is “signing”.
>
>
>
> But this analysis and answer should be written down somewhere so everyone
> doesn’t keep having the same question, especially since some people might
> come to the wrong answer.
>
>
>
> -Tim
>
>
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>