On Thu, 2018-09-20 at 09:26 +0200, Marcel Holtmann wrote:
Hi David,
Yes. It shouldn't be much code, either. You still have to check for X.509
DER since the kernel currently supports that.
For reasons of backward compatibility, correct? The kernel also has
mscode.asn1 which we would need to support as well. Since we can't break
compatibility then perhaps this doesn't buy us a whole lot in the end.
Don't worry about mscode - that's not an asymmetric key parser. That's only
ever used directly from verify_pefile_signature().
Currently, we have to retain support for DER-encoded X.509.
But there's no reason we can't have a PEM parser that decodes the PEM and
selects X.509, PKCS#8 or TPM based on the ascii header in that. PKCS#8 and
TPM don't need to take DER directly.
since we have to support DER-encoded anyway, can we get the current
patches merged (with fixes to the commit messages for the openssl
examples if needed) and then work on PEM support inside the kernel.
For me these seems to be two independent features. And in the current
form the patches have been tested and used.
Or let me ask this differently, are there any objections to merging
these patches with just DER support?
Let me rephrase that question slightly: Are we happy to have to make
inferences from the ASN.1 structure, and in particular that a bare
OCTET-STRING is a TPMv1 blob? I believe James ended up doing something
somewhat more sensible for the TPMv2 blob so that might end up being
OK...?