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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 30 July 2020 18:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA133A08E9; Thu, 30 Jul 2020 11:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIb4VEUhWQBp; Thu, 30 Jul 2020 11:52:07 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2F13A0898; Thu, 30 Jul 2020 11:52:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ADB06389E4; Thu, 30 Jul 2020 14:31:31 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PjOwaLTH1JJd; Thu, 30 Jul 2020 14:31:30 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E211389E2; Thu, 30 Jul 2020 14:31:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E031E281; Thu, 30 Jul 2020 14:52:03 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: openpgp@ietf.org
cc: draft-ietf-sacm-coswid@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 30 Jul 2020 14:52:03 -0400
Message-ID: <29058.1596135123@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/2-n7EiRcSP82VvaJ6pQYu6uUVgM>
Subject: [openpgp] signing COSE (RFC8152) artifacts with openpgp keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 18:52:10 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-