TPM attestation certificate SAN extension format differences

[Alex Seigler]

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

[Manger, James]

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.