Separate cert verification from TUF metadata handling

[ecordell]

This came up in #965 but wanted to bring it up for discussion more broadly.

I think it would be useful to separate out the cert verification from the normal metadata codepaths, something like: certs get loaded/verified -> translated to plain keys -> tuf only deals with plain keys.

This would fix some confusing issues where, for example, data.PublicKey could hold either actual public key bytes or the bytes of a full cert.

This seems like a very clean separation to me; the only issue would be that you would lose the property that certs get verified right before they're used every time. Perhaps it would make sense, after loading the certs into memory, to keep around a map of parsedKeys -> originatingCerts so that at various well-defined points during verification, you can do something like reverifyCerts(currentlyReleventKeyList) to find the certs you're using and check them again.

It would also allow loading in non-cert keys if desired.

Thoughts? Currently cert checking is somewhat scattered throughout notary; consider this a proposal for isolation.

[cyli]

Could you elaborate on both how the certs will be serialized into the TUF metadata files?
Would the public key bytes in the TUF role->key definitions still contain certs, for instance, and we'd just separate the two when we loaded the files themselves?

[ecordell]

Could you elaborate on both how the certs will be serialized into the TUF metadata files?

I was proposing that certs not be serialized at all, instead only their public key bytes. That introduces some distribution issues with certs, though.

In retrospect I'm not sure it matters too much. I think what's important is that everything that takes a cert or a plain key right now should accept both, and verify if it's a cert.

Part of why I think that's important is that external PKI is specifically listed as not an assumption of TUF, so I don't think it should be a requirement for Notary. (Though certainly no reason to prevent it if desired).

[cyli]

@ecordell Agree that we it would probably be good to separate the code that does the cert validation - I think that almost all of it is currently isolated in the trustpinning package, and applies to root only. If you have any further cleanups to suggest for making the cert requirements be more modular please let us know!