The current GPG-based implementation of commit signing in Fossil has a bunch of problems:

1. It depends on an external program that may not be available. (gpg)

2. There is nothing in Fossil (AFAICT) that checks these signatures.

3. We can't write such code, because the PGP ASCII armor signature format doesn't contain the signer's public key, and Fossil itself has no PKI to distribute them. If I have a commit signed by "drh", how do I get his public key to verify the signature of the commit he purportedly signed? What if a distinctly less notable personage like wyoung signed it; how do you get my public key, given only the Fossil user name in the commit manifest's U card?

The patch by rkeene to add S/MIME support to Fossil just extends Fossil's current "ignore the signature" behavior, allowing it to also ignore the S/MIME wrapper on such signed manifests.

This patch presumably also depends on an external program called via Fossil's clearsign setting (openssl smime), and it doesn't add a signature verification feature, but because the PKCS#7 file format that S/MIME is based on can optionally include the public key of the signer, and openssl smime does seem to do this, this might solve problem #3 above. In effect, the Fossil repository becomes the PKI: each signed commit will include not just the signature but also the public key of the signer.

That said, I can't verify the test message referenced by rkeene:

---

/usr/local/Cellar/openssl\@1.1/1.1.1g/bin/openssl smime -verify < msg
Verification failure
4425489856:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:crypto/pkcs7/pk7_smime.c:285:Verify error:unable to get local issuer certificate

---

Where do I get this "local issuer certificate"? Do we need to include that in the S/MIME wrapper as well, to avoid falling into the "just create a PKI" trap?

I'm not sure if my comment will be "on topic", but anyway: IMHO there is no easy escape from distributing public keys within a repository (not really a full-blown PKI).

Firstly, because as a decentralized system, IMHO fossil cannot depend on some kind of central keyring (or external PKI).

Secondly, because in different repositories one may want to use different keys (also "unpublished" elsewhere).

Thirdly, because by relying on an external PKI, we de facto give it control over the verifiability of commits in our own repo, so we have to place full trust in it (similarly to https), and personally I would prefer to avoid it even at the cost of the lack of a signing mechanism in fossil. ;-)

Fourthly: I think we don't really need a PKI - just a verifiable storage of repo-users' public keys. If users would be allowed to upload own public key, and any other user could sign this uploaded key (confirming its authenticity), then all it is needed is to get a key (by any method: downloading form website, sending on paper or dictating over the phone) of any user of this repo who signed enough other users keys to get full coverage of repository user base. This way anyone will be able to verify the authenticity of the other keys in the repo (this is obviously indirect/transitive trust, but at least I know/choose who I trust - not like in https PKI) and also commits made and signed by them.

Having own key distribution mechanism, fossil could add also own key generation and verification mechanism. Or better: use an easy-to-use already exiting one (like OpenBSD's signify). Of course, all this is just "cheap talk" and I am not qualified enough to just send a diff... :-/

One more thing: public key could identify an user, so it could be treated as a personal data within the meaning of the GDPR. So a way to remove it from repo contents could be desirable.

For what it's worth, there's no reason that S/MIME verification (openssl smime) would depend on an external program, it can all be done using the OpenSSL library.

PKCS#7 digital signatures do indeed always(?) carry the X.509 certificate of the signer (otherwise you wouldn't easily be able to verify the identity of the signer, and thus lack non-repudiation).

The certificate in the example was signed by a made up certificate signer, since that's pretty much trivial:

$ cat smime-example.txt | ... | openssl pkcs7 -print_certs -inform DER | openssl x509 -noout -text
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 20120305231428 (0x124c9fa56644)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Test, OU=Test, OU=Test, OU=test, CN=test
        Validity
            Not Before: Mar  5 23:14:31 2012 GMT
            Not After : Mar  5 23:14:31 2013 GMT
        Subject: C=US, O=Test, OU=Test, OU=Test, OU=Test, CN=Whatwhat
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:db:04:73:37:ff:65:1a:a1:84:64:0e:e9:cd:ee:
                    36:7a:e3:1a:c6:11:0e:9d:63:08:e8:88:ff:27:eb:
                    39:21:a1:3a:a1:bc:eb:a1:06:51:f8:ba:0b:67:cd:
                    9b:bb:ee:ab:8c:19:23:5d:b7:9c:74:dc:14:7e:c1:
                    07:97:a1:91:84:92:79:4c:25:08:ee:eb:10:8f:61:
                    00:cd:b9:ac:f9:62:9b:02:4e:72:b1:12:68:8a:47:
                    9c:b1:21:8b:f3:b8:c2:44:85:38:4f:77:92:da:ef:
                    7f:02:ee:d9:e6:cb:43:32:e1:b9:82:06:d5:eb:00:
                    e5:08:8f:b1:a1:f5:86:1d:cc:a8:cc:00:0a:ba:b6:
                    f4:01:69:1c:55:fc:6b:40:13:fe:07:62:e1:a2:ec:
                    14:1d:06:4d:16:61:d7:36:b9:67:d3:e6:4b:ce:b8:
                    a6:e3:a7:d0:6d:27:26:3b:67:ec:6e:63:cc:48:93:
                    e5:1a:06:17:6f:14:5e:4f:e6:df:e0:c9:d0:c9:8f:
                    77:ad:9f:6f:e9:1e:58:1c:e7:6a:f3:ac:f9:5e:23:
                    1b:4d:90:2a:d1:cd:77:ef:7f:53:51:cf:32:6c:65:
                    c1:7f:ee:56:02:46:e5:5f:1f:21:39:2b:4b:a5:40:
                    3e:43:75:83:28:69:cd:20:39:86:b8:86:6c:70:18:
                    b3:b3
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
         d1:3c:68:ae:60:ad:e5:97:c9:23:b5:05:df:2c:0f:8a:c2:0d:
         05:c5:fa:62:a2:a1:3a:cc:fb:6e:fc:b9:55:2f:b3:55:c8:25:
         d5:fa:f8:e7:83:ea:8f:f2:2c:24:8f:b0:40:d7:5e:9d:f1:67:
         7b:49:b4:24:7e:24:1d:4f:9b:78:e3:4b:7d:32:57:79:cb:4a:
         b0:ba:41:7c:00:de:e9:0a:b7:d5:6c:13:8f:af:ed:2e:1a:23:
         d0:88:db:d3:8c:68:26:4d:b6:51:59:c5:6c:3b:de:25:67:3a:
         30:12:65:9b:7e:e9:3d:ce:a6:b7:d9:53:11:e2:4d:d8:34:e5:
         41:5c:42:b9:a4:a0:52:a9:db:1b:62:c2:ae:97:c3:ab:f0:f5:
         5b:ff:51:3f:a7:26:1f:68:85:12:b3:bd:f6:96:bf:6e:42:75:
         d2:57:ac:b8:d4:7d:13:d0:86:33:2d:86:b2:33:a1:64:00:b1:
         7e:da:9d:89:de:77:f3:8c:9d:71:3b:b4:a8:1a:ca:36:f1:7a:
         26:3a:c0:4b:89:07:ec:8e:12:53:72:9c:0b:09:84:a3:33:55:
         5c:eb:7d:f1:b8:5b:2e:81:82:4f:99:3d:5e:8e:fb:8b:75:2c:
         5c:71:ba:5c:49:81:13:64:0b:86:a7:42:1f:11:04:77:7d:1c:
         cb:d4:bb:0a

So the "local issuer certificate" would be C=US, O=Test, OU=Test, OU=Test, OU=test, CN=test (which you don't have, since it's something I just made up for the example).

Certainly one way to get this identity is a web-of-trust style signing system, but most organizations will probably want verification to be centralized into certified signers.

Do we need to include that in the S/MIME wrapper as well, to avoid falling into the "just create a PKI" trap?

Ideally Fossil would have a certificate store with Root CAs as well as intermediate CAs, that users could supply their own certificate trees. I certainly wouldn't trust whatever CA you guys came up with to verify my users identities and attributes.

ravbc on 2020-10-22 17:06:56:

One more thing: public key could identify an user, so it could be treated as a personal data within the meaning of the GDPR. So a way to remove it from repo contents could be desirable.

A public key is definitely personal data if it could be connected to a natural person (as opposed to say a company.) So yes, in most cases it is. But just because something is personal data does not mean that the owner can successfully request it be removed as discussed here.

This problem has been discussed many times in the context of public keyservers. The main corner case that comes up that I can recall is that of somebody's public key being posted without permission - but hacked/stolen personal data may be uploaded to many public websites, and we have ways to deal with that even if they aren't beautiful. Apart from that, contributing a public key is essential to the operation of the service, that is the entire point. That strongly suggests there is a lawful basis for processing the personal data. The GDPR allows for continued processing in some circumstances, even if the data subject withdraws consent.

As another corner case, I don't believe that a revocation certificate is a withdrawal of consent either.

It is worth pointing out that a public key is associated with an email address, and Fossil doesn't currently publish email addresses, so that is an expansion of personal data.

Summary: I don't think the GDPR requires Fossil a way of removing a public key from repo contents, beyond the nuclear option of damaging the DAG that exists already.

Dan