Subject: [openpgp] signing COSE (RFC8152) artifacts with openpgp keys

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2020 14:52:03 -0400

Hi, there is a use case in Software Bill of Materials work (SBOM), where we'd
like to integrate into current open source practices easily.
Open source projects usually announce new releases with a PGP signed email,
a PGP signed git commit, and/or PGP signed tar.gz, usually with a detached
signature.
The community has developed (web-of-)trust in the release key.
(Although in my experience given that I don't have a password that says
"TCPDUMP Group", it is often difficult to get people to sign that key, so the
web-of-trust is less solid than I'd like)

In a number of fora, we are suggesting use of RFC8152 (COSE) objects.
One example is draft-ietf-sacm-coswid-15, but there is other work at OMG as well.

I would rather not force developers to generate some new key with some new
tool.  I'd like to let them use their existing PGP keypair(s).
Let's forget the software work to make this happen for the moment.
(There certainly could be challenges if the key is in a hardware token, and
it won't generate raw signatures needed for COSE)

Do you think it's appropriate to use the primary key?
Would you consider that a specific purpose subkey would be better?

It's likely we'd always want to use ECDSA (or EdDSA), so if the primary key
wasn't ECDSA, then generating a new subkey would be required anyway.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Santiago Torres-Arias <[email-masked]>
Date: Thu, 30 Jul 2020 17:21:27 -0400

Hi, Michael.

My very personal take on this is:

> Do you think it's appropriate to use the primary key?

I'd assume that any key that's tagged as a signing subkey would be the
appropriate one for this. Generally, primary keys are mainly used for
certification and can be used for signing. I think either a primary key
or a subkey as long as it is marked for signing.

> Would you consider that a specific purpose subkey would be better?

I think in general that is up to the owner of that particular set of
keys to decide how to split the functions between his primary key and
subkeys.

> wasn't ECDSA, then generating a new subkey would be required anyway.

Not sure if this is completely necessary to determine, there are many
algorithms that can fit the bill (say, ed25519 is supported in gnupg
for a little while)...

Cheers!
-Santiago