RFC: S/MIME instead of GPG

[hlieberman]

Description of issue or feature request:
Feature Request

Current behavior:
in-toto uses GPG.

Expected behavior:
in-toto uses S/MIME or GPG.

While GPG is great for many things, if you already have an established PKI infrastructure that uses client certificates, setting up yet another PKI hierarchy can be annoying. It would be awesome if in-toto would let you use that hierarchy -- for additional security, would be helpful if you could combine secure timestamping to ensure that the certificates were valid at the time of signing.

Before I start trying to convince my company to spend the time to do this work, though, I want to test the waters from folks to see if it's something that would even be acceptable. Happy to expand more on how I think the design should work as well.

[SantiagoTorres]

Hi @hlieberman ! Sorry this PR slipped through the cracks. I think it'd be rather cool to take a look at S/MIME for signatures, although I'll confess I'm way more familiar with how RFC4880 works than wherever S/MIME is encoded.

I do want to say that we do not support the full RFC4880 standard (e.g., we don't really make any decisions about the trust model on keys), and rather we gate trust using the information stated in the in-toto layout. I wonder if we could elegantly merge S/MIME semantics into the trust model of in-toto. Do you know what'd be a good place to start reading?

[hlieberman]

Hi @SantiagoTorres! No apologies needed; this is all still pretty high level hypotheticals at this point.

In terms of S/MIME signature format, it basically uses PKCS#7/CMS under the hood. I believe the latest specification is RFC3851. In terms of the trust model, you have two different paths you could go down. The way that adheres closest to the way in-toto currently does things would simply to encode the public keys into the in-toto layout; at that point, you're basically just changing the underlying cryptographic library and the disk format of the signatures, but not a whole lot else.

The other (IMO more interesting) approach would be to let you specify a CA or certificate attributes in the in-toto layout. That would let you do things like say "anyone in OU=Engineering can commit code for step 1, but only OU=QA can approve it for step 2, and only CN=buildd*.company.example can produce the final bundle". Then in-toto can not have to deal with the mechanics of the actual users' cryptographic lifecycles. It's all handled externally, and all in-toto has to do is confirm the signatures match the requirements specified. (This involves CRL or OCSP checking, and potentially some form of trusted timestamping so you can determine whether a particular commit was done before a key was revoked or not.)

[lukpueh]

Many thanks for your input, @hlieberman!

... encode the public keys into the in-toto layout; at that point, you're basically just changing the underlying cryptographic library and the disk format of the signatures, but not a whole lot else.

This basically describes our GPG support. It is only relevant for signing. When it comes to verification the keys (contained in a layout) and signatures (contained in links) are detached from any local GPG keyring or global web of trust.

The other (IMO more interesting) approach would be to let you specify a CA or certificate attributes in the in-toto layout ...

This indeed sounds interesting. Do I understand correctly that you suggest to support a usage mode, where an in-toto layout doesn't include public keys at all but instead defines a trusted CA and then maps keys under that CA to supply chain steps using certificate attributes?
If that's correct it would make in-toto more dependent on external infrastructure. But I do like the idea and I'm all for looking into it in more detail, provided that it does not replace the existing usage mode. :)