On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote: > I'd like both backwards and forward compatibility actually, exactly > like x509. If an informational field is added like the key usage that > I mentioned, I doubt you'd like all the previous consumers > incompatible.
OK, so there's a fundamental difference between a v3 X509 certificate and a TPM key: An X509 certificate is a signature over a set of v1 TBS data, a public key and a bundle of attributes. To verify the certificate or extract the key, you don't need to know what the attributes are, so you can still "use" the certificate in that form. However, you can't get the v1 tool to obey the v3 constraints on the certificate because it doesn't understand them. The ASN.1 description of a TPM key contains the actual binary representation of the key plus a set of information which explains to the consuming code how to use the key. Since I can't think of a way of making use of the key without understanding all of the information about how to use it, I think it is beneficial that v1 consumers don't try to use v2 key information because the resulting failure will excite the TPM's dictionary attack protection. I gave an example of one such extension: policy authorisations, but they're definitely of the "if you don't understand these, you can't use the key" variety. Perhaps if you can give an example of a potentially compatible extensions it would help me to see your point and give us a means of moving forwards. Thanks, James > For other extensions which make the structure totally incompatible > you can use the critical flag. Anyway even the original struct is OK, > it is exactly like any other key structs we have. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
