Attestation Attributes for use with Certificate Requests

2.1. Object Identifiers

This is a place holder for actual assignments. It's possible there's already a pkace for the attribute OID assignments.¶

        id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

        -- Branch for CSR and related attributes - IETF version of id-at
        id-pkix-at OBJECT IDENTIFIER ::= { id-pkix (tbd) }

        -- Branch for attestation statement types
        id-ata OBJECT IDENTIFIER ::= { id-pkix (tbd) }

2.2. CertificateChoice

This is an ASN.1 CHOICE construct used to represent an encoding of a broad variety of certificate types.¶

        CertificateChoice ::=
          CHOICE {
            cert Certificate, -- typical X.509 cert
            opaqueCert [0] IMPLICIT OCTET STRING, -- format implictly known
            typedCert [1] IMPLICIT TypedCert, -- non-X.509 but ASN1 cert
            typedFlatCert [2] IMPLICIT TypedFlatCert -- non-ASN1 cert
        }

"Certificate" is a more or less standard X.509 certificate. "opaqueCert" should be used sparingly as it requires the receiving party to implictly know its format. It is encoded as an OCTET STRING¶

"TypedCert" is an ASN.1 construct that has the charateristics of a certificate, but is not encoded as an X.509 certificate. The certTypeField indicates how to interpret the content field. Note that it is possible to use this field to convey a bare public key as well.¶

        TYPED-CERT ::= TYPE-IDENTIFIER -- basically an object id and a matching ASN1
                               -- structure encoded as a sequence
        CertType ::= TYPED-CERT.&id

        TypedCert ::= SEQUENCE {
          certType     TYPED-CERT.&id({TypedCertSet}),
          content      TYPED-CERT.&Type ({TypedCertSet}{@certType})
        }

        TypedCertSet TYPED-CERT ::=
          ... -- Empty for now,
        }

"TypedFlatCert" is a certificate that does not have a valid ASN.1 encoding. Think compact or implicit certificates as might be used with smart cards. certType indcates the format of the data in the content field.¶

        TypedFlatCert ::= SEQUENCE {
          certType OBJECT IDENTIFIER,
          certBody OCTET STRING
        }

2.3. AttestAttribute

By definition, Attributes within a Certificate Signing Request are typed as ATTRIBUTE. This attribute is used to contain exactly one attestation statement of a particular type.¶

        id-pkix-at-attestStatement OBJECT IDENTIFIER ::= { id-pkix-at 1 }

        attestAttribute ATTRIBUTE ::= {
          TYPE AttestStatement
          COUNTS MAX 1 -- tentative, maybe delete
          IDENTIFIED BY id-pkix-at-attestStatement
        }

2.4. AttestCertsAttribute

The "attestCertChainAttribute" contains a sequence of certificates that may be used to validate the contents of an attestation statement contained in an attestAttribute. By convention, the first element of the SEQUENCE should contain the object that contains the public key needed to directly validate the attestAttribute. The remaining elements should chain that data back to an agreed upon root of trust for the attestation.¶

        id-pkix-at-attestCertChain OBJECT IDENTIFIER ::= { id-pkix-at 2 }

        attestCertChainAttribute ATTRIBUTE ::= {
          TYPE SEQUENCE OF CertificateChoice
          COUNTS MAX 1
          IDENTIFIED BY id-pkix-at-attestCertChain
        }

2.5. AttestStatement

An AttestStatement is an object of class ATTEST-STATEMENT encoded as a sequence fields, of which the type of the "value" field is controlled by the value of the "type" field, similar to an Attribute definition.¶

        ATTEST-STATEMENT ::= CLASS {
          &id    OBJECT IDENTIFIER UNIQUE,
          &Type      -- NOT optional
        } WITH SYNTAX {
          TYPE  &Type
          IDENTIFIED BY &id
        }

        AttestStatement { ATTEST-STATEMENT:IOSet}  ::= SEQUENCE
        {
          type ATTEST-STATEMENT.&id({IOSet}),
          value ATTEST-STATEMENT.&Type({IOSet}{@type}),
          algId [0] IMPLICIT  OPTIONAL AlgorithmIdentifier,
          signature [1] SignatureChoice OPTIONAL -- note NOT implicit
          ancillaryData [2] IMPLICIT  OCTET STRING OPTIONAL
        }

Depending on whether the "value" field contains an entire signed attestation, or only the toBeSigned portion, the algId field may or may not be present. If present it contains the AlgorithmIdentifier of the signature algorithm used to sign the attestation statement. If absent, either the value field contains an indication of the signature algorithm, or the signature algorithm is fixed for that specific type of AttestStatement.¶

Similarly for the signature field, if the value field contains only the toBeSigned portion of the attestation statement, this field should be present. In the case of an attestation with the signature present, it's desirable but not mandatory that the signature is over the DER encoding of the value field.¶

The ancillaryData field contains data provided externally to the attestation engine, and whose content and format is not under the control of the attestation engine. For example, this field might contain a freshness nonce generated by the relying party, a signed time stamp, or even a hash of protocol data or nonce data. See below for a few different examples.¶

An example of how to define an AttestStatement object might be: (Note - confirm "WITH COMPONENTS syntax is usable here")¶

        id-mikes-attest-attribute OBJECT IDENTIFIER ::=  { enterprise  nthperm(50924) attest(999) }

        MikesAttest ATTEST-STATEMENT ::= { TYPE OCTET STRING
          IDENTIFIED BY id-mikes-attest-attribute }
          (WITH COMPONENTS algId, signature, ancillaryData)
        --

That would define an attribute where the value field is of type OCTET STRING, and where all three of the optional fields are present. Additional text would identify the expected signature algorithms and the contents of the ancillaryData field under various uses.¶

2.6. SignatureChoice

"SignatureChoice" allows for the encoding of the signature field of the attestation either in the common ASN.1 form of a BIT STRING or as an OCTET STRING. While not expressed in the AttestStatement structure, the type of this field should be consistent with the "type" of the attestation statement.¶

        SignatureChoice ::= CHOICE {
            bs BIT STRING,
            os OCTET STRING
        }

A.1. Sample TPM V2.0 Attestation Attribute

What follows is a sample ATTEST-STATEMENT for a Trusted Platform Module (TPM) V2.0. This is a first pass without validating the results.¶

        id-ata-tpmv20 OBJECT IDENTIFIER ::= { id-ata (tbd) }

        TpmV20Attest ATTEST-STATEMENT ::= {
          TYPE OCTET STRING
          IDENTIFIED BY id-ata-tpmv20 }
          (WITH COMPONENTS signature)

This attestation is the result of executing a TPM2_Certify command over a TPM key. See [reftobeprovided] for more details.¶

The data portion of the value field encoded as OCTET STRING is the attestationData from the TPM2B_ATTEST produced by the TPM. In other words, strip off the TPM2B_ATTEST "size" field and place the TPMS_ATTEST encoded structure in the OCTET STRING data field.¶

The algId is absent as the signature field contains that information.¶

The signature field is an OCTET STRING containing the TPM encoded TPMT_SIGNATURE structure.¶

The ancillary field may be absent if no data is provided, or if the signing scheme is not Anonymous. In the latter case, it may duplicate data already in the TPMS_ATTEST structure. If present, this is the buffer field of the TPM2B_DATA structure passed to the TPM2_Certify command as the qualifyingData argument.¶

An AttestCertChain attribute must be present if this attribute is used as part of a certificate signing request. The first certificate of that chain should be the TPMT_PUBLIC structure representing the key to be attested. If the key used to sign the attestation has been previously enrolled as an attestation key, then the next certificate of that chain should be the certificate containing the attestation key.¶

If the attestation key has NOT been issued a certificate, ... tbd. There is a scheme to allow for a two step attestation process based on the TPMs endorsement key and a user's TPM generated Attestation key that will not require multiple round trips. This requires validating the TPMs built in endorsement key pair, the user generated attestation key, and finally the user's key they are trying to get enrolled for what ever use is specified in the current CSR.¶