Clarify requirement 19: ASCII vs. Binary signature

[tschmidtb51]

We should clarify whether we expect signatures to be in ASCII or binary format or both should be accepted. Therefore, we need to figure out whether it make a difference for implementers.

[bernhardreiter]

The question should be evaluated for public key files as well. Relevant languages to check would include Java, Rust and Go (according to @tschmidtb51).

[bernhardreiter]

In general: Any additional variant will make a standard a little bit harder to understand, write and read. And several little variants will easily multiply the difficulty. So personally I'd rather allow one variant less unless it is really having a significant advantage. So the burden of proof would be on the proposed enhancement from my perspective.

There are two possible advantages for allowing both file formats for signatures and public keys:

• An implementation would not need to transform (or recreate) the files if it got them already in one of two formats.
• The binary files could save a bit of space as they are more compact.

CSAF 2.0 documents are in JSON, which is quite verbose. Compared to those documents, the size increase by using ASCII armored signatures and public key file is just a little. So if one format is to be selected, ASCII armored seems to be the better fit with in the CSAF 2.0 family of files.

For implementations that find and read CSAF documents, the potential drawback is that they may need to transform the files before processing.

In order to find out how implementations behave I focus on the parsing side of the files.
Reading happens more often than writing (and I lack data about what files are already existing on the potential CSAF Trusted Provider sides).

The next steps are to check which preferred methods for reading pubkeys and checking signatures are for the different languages.

GnuPG

And elder version of gpg (GnuPG) 2.2.40
does not make a difference when checking a detached signature as ascii or binary format.
Importing also behaves the same.

(Using GnuPG via the library GPGME is a common method to interact with GnuPG, which is a widespread OpenPGP implementation. It is used by many other programming languages.)

Java

https://gh.pgpainless.org/ or https://www.bouncycastle.org/

TODO

Rust

• https://github.com/rpgp/rpgp

TODO

Go

https://github.com/ProtonMail/gopenpgp is a common choice if an OpenPGP/LibrePGP library in Go is wanted.
It is a fork from the Go standard library module, which is deprecated now.

Also used by https://github.com/csaf-poc/csaf_distribution.

Ease of implementation

Doing a documentation level research:
https://pkg.go.dev/github.com/ProtonMail/gopenpgp/[email protected]/crypto#PGPVerify

especially VerifyDetached() offers the option to set encoding to Auto which detects unarmored or armored detached signaturs.

https://pkg.go.dev/github.com/ProtonMail/gopenpgp/[email protected]/crypto#NewKey
also accepts both types.

So if the general functions are used to begin with, there is no extra
code when reading pubkeys or signatures in both formats.

[sthagen]

"requirement 19" is a to me unclear reference. Can we rename the ticket or name the CSAF v2.0 or v2.1 specific target? Thanks.

[tschmidtb51]

"requirement 19" is a to me unclear reference. Can we rename the ticket or name the CSAF v2.0 or v2.1 specific target? Thanks.

It is kind of independent of the version - the requirement is still the same. But I guess, we will focus first on CSAF 2.1

[sthagen]

I think I was not clear, sorry. My question is, what the relevance of "requirement 19" is, where I can find that ... or if this is some "catalog of requirements" not related to our specification but to some contract or suggested tool. Thanks.

[tschmidtb51]

I think I was not clear, sorry. My question is, what the relevance of "requirement 19" is, where I can find that ... or if this is some "catalog of requirements" not related to our specification but to some contract or suggested tool. Thanks.

I'm sorry - my bad: The issue refers to the requirement 19 from section 7.1.19.