Hello,
We’ve recently started seeing a different SAN extension format in some TPM attestations. WebAuthn says “The Subject Alternative Name extension MUST be set as defined in [TPMv2-EK-Profile] section 3.2.9”. Section 3.2.9 of the TCG EK Credential Profile says “The issuer MUST include TPM manufacturer, TPM part number and TPM firmware version, using the directoryName-form within the GeneralName structure. The ASN.1 encoding is specified in section 3.1.2 TPM Device Attributes”. Based on the sample in section A.1 Example 1, the structure should look roughly like this:
SEQUENCE
SET
SEQUENCE
OID
STRING
SET
SEQUENCE
OID
STRING
SET
SEQUENCE
OID
STRING
But what I’ve been seeing the past few years is this format that does not match the spec:
SEQUENCE
SET
SEQUENCE
OID
STRING
SEQUENCE
OID
STRING
SEQUENCE
OID
STRING
I have a Dell laptop that produces attestations that do not match the spec. The FIDO conformance tool appears to create attestations that do not match the spec. A colleague of mine has a Dell laptop that produces attestations that do match the spec. Examples below.
Mine (“bad”): https://lapo.it/asn1js/#MD6kPDA6MTgwDgYFZ4EFAgMMBWlkOjcyMBAGBWeBBQICDAdOUENUNzV4MBQGBWeBBQIBDAtpZDo0RTU0NDMwMA
Theirs (“good”): https://lapo.it/asn1js/#ME2kSzBJMRYwFAYFZ4EFAgEMC2lkOjUzNTQ0RDIwMRcwFQYFZ4EFAgIMDFNUMzNIVFBIQUhDMTEWMBQGBWeBBQIDDAtpZDowMDRBMDAwOA
Question is, has anyone else seen this, and if so what are they doing about it? I poked around at some open source servers and they all seem to accept the “bad” format and reject the “good” format, there is also the FIDO conformance tool to take into account. I also went back through older versions of TCG EK Credential Profile to try to determine when/why the example was added because there are very few examples given, there must have been some sort of issue or problem that came up that prompted the example to be given. I found some older versions 12+ years ago that have a less verbose explanation of how the SAN is supposed to be formatted and it didn’t have the examples but that’s as far as I got.
Thanks,
-aseigler
A directoryName is a path in a directory. Each step down the directory’s hierarchy is identified by 1 *or more* attributes.
The A.1 example names a directory entry 3 layers deep (as does your colleague’s example):
- tpmManufacturer “id:54534700” <- top entry
+- tmpModel “ABCDEF123456” <- child entry
+- tmpVersion “id:00010023” <- child-of-child entry
Your example names an entry in a flat directory with 1 layer. Entries in that layer need 3 attributes to distinguish them:
- tpmManufacturer “id:54534700”, tmpModel “ABCDEF123456”, tmpVersion “id:00010023” <- top entry
Both are syntactically valid directoryNames.
I have no idea which was intended for TPM, nor which is supported where.
--
James Manger
From: fido...@fidoalliance.org <fido...@fidoalliance.org>
On Behalf Of Alex Seigler
Sent: Wednesday, 9 September 2020 11:42 PM
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] TPM attestation certificate SAN extension format differences
[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. |
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit
https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/DM6PR04MB607466FB8D35008DE515649CBC260%40DM6PR04MB6074.namprd04.prod.outlook.com.