[arch-dev-public] Signing enclave

[Morten Linderud]

On Sat, Jan 29, 2022 at 06:22:29PM +0100, Kristian Klausen via arch-dev-public wrote:
> Signing:
> - SSHing to a restricted UNIX user with ForceCommand=signing-script
> - All signing operations are logged
> - Only signing requests from gemini's WireGuard IP address is allowed

Some general thoughts about how we suppose to log these options.

We should preferably use a Transparency Log for these as it would give us
tamper evidence if our signing enclave gets compromised.

For people unfamiliar with Transparency Logs; https://transparency.dev/verifiable-data-structures/
It's the same technology as Certificate Transparency; https://datatracker.ietf.org/doc/html/rfc6962

We have few options here:

* Implement our own Trillian Log
* Use an existing implementation
* Use sigstore[1].

I'm a bit biased towards just using sigstore as it's essentially a continuation
of stuff i wrote about in my master thesis. It's also fairly trivial to
integrate towards and we don't need to host anything ourself. It's also funded
by our own Santiago :)

We would be using `rekor-cli` which would give us a lot of this for free.[2]

The other option is hosting our own log. This is not super trivial as we want
monitors and people replicating the log outside of our own organization to
ensure nobody can tamper with the log. The LVFS has opted for such an
implementation.

I personally think this is an important part of our signing infrastructure.

In the future we could have pacman ensure database signatures are present on the
Transparency Log which would prevent most of the trivial compromises of our
signing enclave.

Does anyone have any opinions around this or have any questions?

[1]: https://www.sigstore.dev/
[2]: https://docs.sigstore.dev/rekor/CLI

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220129/bf10592e/attachment.sig>