BACA and EnmaCA used to just wing the issuer name. That was a bad idea.
It turns out that the issuer name must match the subject name of the
higher-level certificate exactly (apparently; at least it works when I
do that and it does not if I do not). Adhering to that is not quite
trivial because I find it rather difficult to read the subject name from
a certificate with mbedtls; so the implementation is a bit rough here,
but it works. (I take mbedtls’s representation of the ASN.1 list,
reverse it (because apparently mbedtls reverses it while reading) and
just stuff it directly into the mbedtls_x509write_cert).
Checking was also broken. I thought mbedtls’s verify function verified
all of the certificates passed to it. It does not. Instead, from what
I can tell, it only verifies the very first one; it just uses the rest
to get from the first one to the root CAs. Before this commit, BACA and
EnmaCA pass the intermediate certificates first, so that is why even
though BACA’s AIKC generation was broken, EnmaCA did not notice, because
it just verified the first intermediate certificate.
Fix this by only verifying one certificate at a time, pass it as the
first one in the chain and only append the intermediate certificates to
it, not the other way around.
The CAs doing what they should be doing primarily, which is they issue
certificates. What especially BACA currently does not do is correct
verification; it just checks the certificate chain and that the other
side is in possession of the endorsement key. It does not check the
certificates themselves (so it does not check for TPM features or things
like that). This is not least because mbedtls simply does not support
the x509 extensions used for those certificates. But on the other hand,
this is not too bad, it just means that it is up to the user to be
careful which root and intermediate CAs to trust.
mbedtls has to be included in this repository because the one real EC I
have prefers to be correct and mark the issued key as rsaesOaep. Which
is not supported by mbedtls as-is. Even openssl cannot display such a
key. But if you just handle that key as a normal RSA key and ignore its
parameters (which is the OAEP label "TCPA", as defined by the TPM
specification), we can verify the certificate and extract the EK from
it. But still, we have to modify mbedtls for that to work.
(And also we need to make it ignore critical certificate extensions it
does not know (MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION),
because there are a couple of those in an EC.)