Internet-Draft CSR Attestation Attributes May 2023
StJohns Expires 6 November 2023 [Page]
Intended Status:
M. StJohns
NthPermutation Security LLC

Attestation Attributes for use with Certificate Requests


This document describes two ASN.1 Attribute definitions that may be used to carry key attestation data in PKCS10 certificate requests and in other circumstances.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 November 2023.

Table of Contents

1. Introduction

This document is intentionally incomplete as it is a counter-offer to two other Internet Drafts currently being considered by LAMPS for adoption or progression.

Unlike the other proposals, this document attempts to describe an encoding that may be used regardless of the actual format and mechanisms used by an given type of attestation. To do that it defines two Attributess: the first to carry the attribution statement, any ancillary or externally provided information for the statement (e.g. a freshness nonce), and the signature over the attestation statement; the second to carry one or more certificates which may be used in the validation of the attestation statement.

For the purposes of this document, a "certificate" is a signed binding of a public key and some identifying or use information. An X.509 Certificate is one example, but the structures described below allow for the specification of pretty much any type of certificate imaginable.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. ASN.1 Elements

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.

          &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) }

          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

3. IANA Considerations

Placeholder - two new registries to be opened; one for general/csr attributes, another for attestation statement types

4. Security Considerations


5. References

5.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

5.2. Informative References

Appendix A. Examples

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 ::= {
          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.

Appendix B. ASN.1 Module for Attestation

      Place holder for the complete and verified ASN.1

Author's Address

Michael StJohns
NthPermutation Security LLC
Germantown, MD 20874
United States of America