Attest to keys, not certificates

[jethrogb]

On https://github.com/jlmucb/cloudproxy/blob/master/go/tao/auth/ast.go#L110 it is stated that Key might be a DER-encoded X.509 certificate. Why not just a DER-encoded SubjectPublicKeyInfo?

Done: jlm

[tmroeder]

This is allowed; maybe we should clarify the comment. The types of key values named there are merely the ones that the Tao happens to use. There's certainly no reason to not use SubjectPublicKeyInfo; at the moment, we use a custom protobuf-wrapped key out of convenience.

I was going to say that you could simply write a function like tao.FromPrincipal in tao/keys.go, but you can't, since the attestation code is hardcoded to expect a CryptoKey protobuf, and the internals of tao.Verifier are not exported.

For the moment, this isn't high priority for us to fix, but I'll leave this open; at the very least, I could export the internal ec element of Verifier and Signer so external code could create them out of auth.Prin with other types.

[jethrogb]

Currently there is nothing in the encoded version to indicate what kind of thing is serialized as a key. This means a third party verifying a statement can only guess at what is in there, which is not very cryptographically sound.

I think you should either standardize on a key format or include a way to specify the type of key.

[tmroeder]

John suggested that too a while ago. I agree with the comment from an engineering point of view, and I think I'll probably add it in the future. However, I don't follow the claim about cryptographic soundness. Can you provide an example of this that doesn't involve breaking the crypto algorithm used to generate the signature?

Given that a key-based auth.Prin represents the name of a principal, it is only ever going to be a public key. So, consider the actions of a receiver of an auth.Prin:

A receiver is going to deserialize the format in some way that it decides is right (and this is clearly an engineering problem for the current version). Either the deserialization succeeds or not. If not, then verification fails. If deserialization succeeds, then the receiver has a key. If it's the wrong key, then either verification fails correctly or the signature scheme is broken (with overwhelming probability). If verification succeeds correctly, then that's the right behavior.

Also, remember that this auth principal is not always getting signed, so the type of the key would be at most a hint to the receiver.

[jethrogb]

I see, you're right about that. I still see two issues:

1. The innermost key (the one which was specified as the actual parameter to the "Attest" call) might not be immediately used to verify an accompanying signature. That might leave room to fool whatever process this key was going to be used for. As an extreme example see Secure Content Sniffing for Web Browsers, or How to Stop Papers from Reviewing Themselves. An X.509 certificate has plenty room for arbitrary data (e.g. in the extensions section), so who knows what that might deserialized as.
2. Trying to deserialize random data in various ways is generally prone to memory safety bugs, but I understand if you claim that's "not my problem".

[tmroeder]

I think these are both good points from a security engineering perspective, and I don't think it's too hard to fix this, so I'll look into it.