Subject: [SCITT] Regarding Envelope Agility: JOSE, COSE and PGP

From: Orie Steele <[email-masked]>
Date: Mon, 11 Apr 2022 14:00:33 -0500

Sorry this is a bit of a ramble...

I take it as a given that this list (and any future SCITT WG) is not going
to define a new envelope format.

This means building on existing standards, which means picking sides in
the war that is data formats (JSON / YAML / CBOR)

This will become a source of political attack for the work, it's better to
just acknowledge this at the beginning, so that we can address it / defend
against it well from the start.

The purpose of my email here is to prove that we live in a "multi-envelop"
reality... and we will in the future.

Here is my evidence:

- NPM and PGP -
https://docs.npmjs.com/about-pgp-signatures-for-packages-in-the-public-registry
- PyPi and PGP -
https://davidfischer.name/2012/05/signing-and-verifying-python-packages-with-pgp/
- Signing Commits
  - https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/
  -
https://docs.github.com/en/github-ae@latest/authentication/managing-commit-signature-verification/signing-commits
- Apache Maven and PGP - https://maven.apache.org/plugins/maven-gpg-plugin/
- Google's work
  - https://developers.google.com/android/binary_transparency
  -
https://security.googleblog.com/2021/10/pixel-6-setting-new-standard-for-mobile.html
- Apple's work
  -
https://support.apple.com/guide/deployment/certificate-transparency-payload-settings-depbafaa79ff/web
- Mozilla's work
  - https://wiki.mozilla.org/Security/Binary_Transparency
- Signing Docker images - (sigstore)
https://github.com/moby/buildkit/issues/2494

The first observation I would make is that PGP is the legacy system you
can't ignore...

The second observation I would make is that Google and Apple need to be a
part of the conversation.

Another observation is "fit for purpose" signature schemes...

Is signing a container like signing a binary?
It is like signing an interpreted language package?
Is it like signing a firmware image?

I hope the answer is obvious... Each of these cases has different
constraints... optimization that is possible in one, damages the potential
to generalize to the others.

To me, this signals the need for a "higher order" abstract data model...
which comes at a cost.

The alternative also comes at cost however, you will need to implement a
different envelope per artifact type...
.. when you finish, will that be better or worse than paying for an
abstract data model up front?

There is a future, where you see a green check mark next to an app, and
clicking into the details, you see a list of standards that covers JOSE,
COSE, PGP, Docker, OpenSSL, DIDs, VCs, etc...

Imagine the cost to independently verify... You can't convert to a lower
number of serializations if you don't have an envelope format that works
for all of them to consolidate too.

I think we all want to see consolidation here, because we don't want to be
forwarding multi suite implementation costs all the way to the developers...

But I also think it's naive to assume we can jump to that future point
without feeling the pain of multisuite verification reality, which we live
in today.

The good news is that the most restrictive suite envelope format (COSE /
CBOR) has an excellent track record of enabling interoperability through
registries.

https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

One question I would pose to the group:

How many new CBOR tags need to be registered in order to be confident in
the software supply chain?

Once that number is known, we will know the number of things that need to
be mapped to JSON to support JOSE or PGP.

Regards,

OS

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>