Attestation Attributes for Use with Certification Signing Requests
draft-stjohns-csr-attest-01

LAMPS                                                         M. StJohns
Internet-Draft                               NthPermutation Security LLC
Intended status: Standards Track                             6 June 2023
Expires: 8 December 2023

   Attestation Attributes for Use with Certification Signing Requests
                      draft-stjohns-csr-attest-01

Abstract

   This document describes two ASN.1 Attribute definitions, and an ASN.1
   CLASS definition for an attestation statement structure that may be
   used to encode key attestation data for inclusion 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 https://datatracker.ietf.org/drafts/current/.

   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 8 December 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

StJohns                  Expires 8 December 2023                [Page 1]
Internet-Draft         CSR Attestation Attributes              June 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  ASN.1 Elements  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Object Identifiers  . . . . . . . . . . . . . . . . . . .   4
     3.2.  CertificateChoice . . . . . . . . . . . . . . . . . . . .   4
     3.3.  AttestAttribute . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  AttestCertsAttribute  . . . . . . . . . . . . . . . . . .   6
     3.5.  AttestStatement . . . . . . . . . . . . . . . . . . . . .   6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  "SMI Security for PKIX Certificate Signing Request
           Attributes" Registry  . . . . . . . . . . . . . . . . . .   8
     4.2.  "SMI Security for PKIX Certificate Signing Request
           Attributes" Registry  . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  10
     A.1.  Simple Attestation Example  . . . . . . . . . . . . . . .  10
     A.2.  Example TPM V2.0 Attestation Attribute - Non Normative  .  11
   Appendix B.  ASN.1 Module for Attestation . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This document creates two ATTRIBUTE/Attribute definitions.  The first
   Attribute may be used to carry a set of certificates or public keys
   that may be necessary to validate an attestation.  The second
   Attribute carries a structure that may be used to carry key
   attestation statements, signatures and related data.  Both of these
   Attribute definitions are intended to be used to carry the
   attestation data a Certification Authority (CA) may need to decide to
   issue a certificate containg the attested key.

   The AttestStatement structure provides an encoding that may be used
   regardless of the actual format and mechanisms used by an given type
   of attestation.  In its simplest expansion it encodes a SEQUENCE of
   an OBJECT IDENTIFIER and a related ASN.1 type.

StJohns                  Expires 8 December 2023                [Page 2]
Internet-Draft         CSR Attestation Attributes              June 2023

   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 carriage of any identifiable type of certificate.
   Examples include Card Verifiable Certificates [TR-03110-3] and [EQMV]
   implicit certificates.

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.  Definitions

   The following definitions should be used in the context of this
   document primarily to understand the relationship of an attestation
   to the ASN.1 structures used to carry an attestation in PKIX
   structures.  As of the date of this document, the IETF lacked a
   common nomenclature for attestation-related terms.

   Attestation Engine
      The secure hardware and firmware used to compose and sign an
      attestation.

   Attestation Key
      Either the private key used to sign an attestation statement, or
      the related public key used to verify the attestation statement,
      depending on context.

   Attester
      The entity that directs the creation of an attestation statement
      and who owns, controls, or is permitted to use the private
      attestation key.

   Ancillary Attestation Data
      Any data provided from a source external to the attestation engine
      as part of the creation of an attestation statement and/or any
      additional data needed for the verification of an attestation
      statement.  The externally provided data could be a relying party
      originated nonce, a time stamp, session information or other data
      meant to be bound in time to the attestation statement.  Other
      additional data may be an internally formatted key, or other data
      needed to bridge between the attestation statement and PKIX or
      other relying or interpretating regimes.  The format of externally
      provided data is not under the control of the attestation engine,
      but may need to be transformed, such as by hashing, before it may
      be incorporated within the attestation statement processing.  For

StJohns                  Expires 8 December 2023                [Page 3]
Internet-Draft         CSR Attestation Attributes              June 2023

      example, a relying party may need both the "externalData" argument
      for the TPM 2.0 TPM2_Certify command, and the TPMT_PUBLIC
      structure containing the key being certified to verify an
      attestation.

   Attestation Statement
      The object, any optional ancillary data incorporated during the
      creation of that object, and the signature over that object,
      created by an attestation engine at the request of an Attester to
      provide evidence of a fact or set of facts within the cognizance
      of the attestation engine at a particular point in time."
      Sometimes referred to simply as an "attestation".

   Attestation
      The implicit or explicit collection of an attestation statement,
      any ancillary data, an attestation key, and a chain of trust for
      that key.  By convention, this contains at least the minimum data
      needed to cryptographically validate an attestation statement and
      extract any policy meaning.

   Key Attestation
      An attestation created with respect to a particular key or key
      pair.

3.  ASN.1 Elements

3.1.  Object Identifiers

   Placeholder for now, waiting on guidance.

   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-cra OBJECT IDENTIFIER ::= { id-pkix (TBD1) }

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

3.2.  CertificateChoice

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

StJohns                  Expires 8 December 2023                [Page 4]
Internet-Draft         CSR Attestation Attributes              June 2023

   CertificateChoice ::=
      CHOICE {
         cert Certificate, -- typical X.509 cert
         opaqueCert    [0] IMPLICIT OCTET STRING, -- Format implicitly agreed upon
                                                           -- by sender and receiver
         typedCert     [1] IMPLICIT TypedCert,
         typedFlatCert [2] IMPLICIT TypedFlatCert
      }

   "Certificate" is a standard X.509 certificate that MUST be compliant
   with RFC5280.  Enforcement of this constraint is left to the relying
   parties.

   "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 certBody field.  While
   it is possible to carry any type of data in this structure, it's
   intended the content field include data for at least one public key
   formatted as a SubjectPublicKeyInfo (see [RFC5912]).

   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 indicates the format of the data in the
   certBody field, and ideally refers to a published specification.

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

StJohns                  Expires 8 December 2023                [Page 5]
Internet-Draft         CSR Attestation Attributes              June 2023

3.3.  AttestAttribute

   By definition, Attributes within a Certification Signing Request are
   typed as ATTRIBUTE.  This attribute definition contains one or more
   attestation statements of a type "AttestStatement".

   id-cra-attestStatement OBJECT IDENTIFIER ::= { id-cra 2 }

   AttestAttribute ATTRIBUTE ::= {
     TYPE AttestStatement
     IDENTIFIED BY id-cra-attestStatement
   }

3.4.  AttestCertsAttribute

   The "AttestCertsAttribute" contains a sequence of certificates that
   may be needed 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-cra-attestChainCerts OBJECT IDENTIFIER ::= { id-cra 1 }

   attestCertsAttribute ATTRIBUTE ::= {
     TYPE SEQUENCE OF CertificateChoice
     COUNTS MAX 1
     IDENTIFIED BY id-cra-attestChainCerts
   }

3.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.

StJohns                  Expires 8 December 2023                [Page 6]
Internet-Draft         CSR Attestation Attributes              June 2023

   ATTEST-STATEMENT ::= CLASS {
     &id                 OBJECT IDENTIFIER UNIQUE,
     &Type,                  -- NOT optional
     &algidPresent       ParamOptions DEFAULT absent,
     &sigPresent         ParamOptions DEFAULT absent,
     &ancillaryPresent   ParamOptions DEFAULT absent,
     &sigType            DEFAULT OCTET STRING
     &ancillaryType      DEFAULT OCTET STRING

   } WITH SYNTAX {
     TYPE  &Type
     IDENTIFIED BY &id
     [ALGID IS &algidPresent]
     [SIGNATURE [TYPE &sigType] IS &sigPresent]
     [ANCILLARY [TYPE &ancillaryType] IS &ancillaryPresent]
   }

   AttestStatement { ATTEST-STATEMENT:IOSet}  ::= SEQUENCE
     {
       type          ATTEST-STATEMENT.&id({IOSet}),
       value         ATTEST-STATEMENT.&Type({IOSet}{@type}),
       algId         [0] IMPLICIT  AlgorithmIdentifier OPTIONAL,
       signature     [1] ATTEST-STATEMENT.&sigType OPTIONAL -- NOT implicit
       ancillaryData [2] ATTEST-STATEMENT.&ancillaryType 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.  The "signature" field may by typed as any valid
   ASN.1 type.  Opaque signature types SHOULD specify the use of sub-
   typed OCTET STRING.  For example:

   MyOpaqueSignature ::= OCTET STRING

   If possible, the ATTEST-STATEMENT SHOULD specify an un-wrapped
   representation of a signature, rather than an OCTET STRING or BIT
   STRING wrapped ASN.1 structure.  I.e., by specifying ECDSA-Sig-Value
   from PKIXAlgs-2009 to encode an ECDSA signature.

StJohns                  Expires 8 December 2023                [Page 7]
Internet-Draft         CSR Attestation Attributes              June 2023

   ECDSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER
   }

   The ancillaryData field contains data provided externally to the
   attestation engine,and/or data that may be needed to relate the
   attestation to other PKIX elements.  The format or content of the
   externally provided data 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.

4.  IANA Considerations

   The IANA is requested to open two new registries and allocate a value
   from the "SMI Security for PKIX Module Identifier" registry for the
   included ASN.1 module.

4.1.  "SMI Security for PKIX Certificate Signing Request Attributes"
      Registry

   Please open up a registry for CSR Attributes within the SMI-numbers
   registry, allocating an assignment from id-pkix ("SMI Security for
   PKIX" Registry) for the purpose.

   Proposed Name: id-cra (id-cra OBJECT IDENTIFIER ::= {id-pkix (TBD) }
   )

   Initial Contents

         +=========+===============================+============+
         | Decimal | Description                   | References |
         +=========+===============================+============+
         | 1       | Attestation Certificate Chain | This Doc   |
         +---------+-------------------------------+------------+
         | 2       | Attestation Statement         | This Doc   |
         +---------+-------------------------------+------------+

           Table 1: Initial entries for CSR Attributes registry

4.2.  "SMI Security for PKIX Certificate Signing Request Attributes"
      Registry

   Please open up a registry for CSR Attributes within the SMI-numbers
   registry, allocating an assignment from id-pkix ("SMI Security for
   PKIX" Registry) for the purpose.

StJohns                  Expires 8 December 2023                [Page 8]
Internet-Draft         CSR Attestation Attributes              June 2023

   Proposed Name: id-ata (id-ata OBJECT IDENTIFIER ::= {id-pkix (TBD) }

   Initial Contents - None.

5.  Security Considerations

   The attributes and structures defined in this document are primarily
   meant to be used as additional Attributes for a PKCS10 Certification
   Signing Request (CSR).  As such, it's up to the receiving/relying
   party to place as much or as little trust in the contents of these
   attributes as necessary to satisfy its own policies.

   A relying party will need either a specification defining how an
   attestation type was formed and how to validate that type, or a
   trusted method of verifying the attestation.  In the former case, a
   relying party should consider the information available from any
   certificate chain covering the attesting key when deciding to accept
   the attestation.

   Most attestations will need to provide a method to convert the
   attested key representation into the equivalent SubjectPublicKey info
   structure and the attested key MUST be compared for equivalence to
   the public key provided in the CSR before accepting the attestation.

   The relying party, as always, is responsible for setting the rules
   for what it will accept.  The presence of an AttestAttribute is not
   required by any current standard, but such attribute may provide the
   relying party with additional assurance as a prerequisite to issuing
   certificates or other credentials.  That acceptance criteria is out
   of scope for this document.  Whether to require an AttestAttribute or
   its contents in any specific use case is out-of-scope for this
   document.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

6.2.  Informative References

   [EQMV]     Certicom Research, "Elliptic Curve Qu-Vanstone Implicit
              Certificate Scheme (ECQV)", Standards for Efficient
              Cryptography SEC-4, January 2013,
              <https://www.secg.org/sec4-1.0.pdf>.

StJohns                  Expires 8 December 2023                [Page 9]
Internet-Draft         CSR Attestation Attributes              June 2023

   [RFC5912]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
              Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
              DOI 10.17487/RFC5912, June 2010,
              <https://www.rfc-editor.org/info/rfc5912>.

   [TPM20]    Trusted Computing Group, "Trusted Platform Module Library
              - Part 1: Architecture", TPM 2.0 Module Library Part1,
              00-01.59, November 2019.

              Trusted Computing Group, "Trusted Platform Module Library
              - Part 2: Structures", TPM 2.0 Module Library Part2,
              00-01.59, November 2019.

              Trusted Computing Group, "Trusted Platform Module Library
              - Part 2: Commands", TPM 2.0 Module Library Part2,
              00-01.59, November 2019.

   [TR-03110-3]
              Federal Office for Information Security, "Advanced
              Security Mechanisms for Machine Readable Travel Documents
              and eIDAS Token - Part 3 Common Specifications V2.21",
              Federal Republic of Germany, Technical Guideline TR-03110,
              December 2016, <https://www.bsi.bund.de/SharedDocs/Downloa
              ds/EN/BSI/Publications/TechGuidelines/TR03110/BSI_TR-
              03110_Part-3-V2_2.pdf?__blob=publicationFile&v=1>.

Appendix A.  Examples

A.1.  Simple Attestation Example

   This is a fragment of ASN.1 meant to demonstrate an absolute minimal
   definition of an ATTEST-STATEMENT.  A similar fragment could be used
   to define an ATTEST-STATEMENT for an opaque HSM vendor specific
   atterstation model.

StJohns                  Expires 8 December 2023               [Page 10]
Internet-Draft         CSR Attestation Attributes              June 2023

   -- This OCTET STRING is not like any other OCTET STRING
   -- Please see https://example.com/simple-attest.txt,
   -- Structure labled "Mike's simple attest" for the
   -- structure of this field and how to verify the attestation

   MikesSimpleAttestData ::= OCTET STRING

   mikesSimpleAttestOid OBJECT IDENTIFIER ::= { id-mikes-root 1 }

   MikesSimpleAttest ATTEST-STATEMENT ::= {
     TYPE MikesSimpleAttestData
     IDENTIFIED BY mikesSimpleAttestOid
     -- These are all implied
     -- ALGID IS absent
     -- SIGNATURE is absent
     -- ANCILLARY is absent
   }

A.2.  Example TPM V2.0 Attestation Attribute - Non Normative

   What follows is a fragment of an ASN.1 module that might be used to
   define an attestation statment attribute to carry a TPM V2.0 key
   attestation - i.e., the output of the TPM2_Certify command.  This is
   an example and NOT a registered definition.  It's provided simply to
   give an example of how to write an ATTEST-STATEMENT definition and
   module.

   -- IMPORT these.
   -- PKI normal form for an ECDSA signature
   ECDSA-Sig-Value ::= SEQUENCE {
     r INTEGER,
     s INTEGER
     }

   -- Octet string of size n/8 where n is the
   -- bit size of the public modulus
   RSASignature ::= OCTET STRING

   -- One or the other of these depending on the value in TPMT_SIGNATURE
   TpmSignature CHOICE ::= {
     ecSig [0] IMPLICIT ECDSA-Sig-Value,
     rsaSig [1] IMPLICIT RSASignature
     }

   -- The TPM form of the public key being attested.
   -- Needed to verify the attestation - this is the TPMT_PUBLIC structure.
   TpmtPublic ::= OCTET STRING

StJohns                  Expires 8 December 2023               [Page 11]
Internet-Draft         CSR Attestation Attributes              June 2023

   -- The TPMS_ATTEST structure as defined in TPM2.0
   -- Unwrapped from the TPM2B_ATTEST provided
   -- by the TPM2_Certify command.
   TpmsAttest ::= OCTET STRING

   -- The qualifying data provided to a TPM2_Certify call, may be absent
   -- This is the contents of data field of the TPM2B_DATA structure.
   QualifyingData ::= OCTET STRING

   TpmAncillary ::= SEQUENCE {
      toBeAttestedPublic TpmtPublic,
      qualifyingData QualifyingData OPTIONAL
      }

   -- This represents a maximally unwrapped TPM V2.0 attestation.  The
   -- output of TPM2_Certify is a TPM2B_ATTEST and a TPMT_SIGNATURE.
   -- The former is unwrapped into a TPMS_ATTEST and the latter is
   -- decomposed to provide the contents of the algId and signature fields.

   --
   -- This attestation statement can be verified by:
   -- Signature siggy = Signature.getInstance (stmt.algId);
   -- siggy.init (attestPublicKey, VERIFY);
   -- siggy.update ((short)stmt.value.length) // todo: big or little endian
   -- siggy.update (stmt.value.data)
   -- bool verified = siggy.verify (getSigData(stmt.signature)); //
   unwrap the signature
   --

   TpmV2AttestStatement ATTEST STATEMENT ::= {
      TYPE TpmsAttest
      IDENTIFIED BY id-ata-tpmv20-1
      ALGID IS present
      SIGNATURE TYPE TpmSignature IS present
      ANCILLARY TYPE TpmAncillary IS present
      }

   This attestation is the result of executing a TPM2_Certify command
   over a TPM key.  See [TPM20] 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 derived from the "sigAlg" field of the TPMT_SIGNATURE
   structure.

StJohns                  Expires 8 December 2023               [Page 12]
Internet-Draft         CSR Attestation Attributes              June 2023

   The signature field is a TpmSignature, created by transforming the
   TPMU_SIGNATURE field to the appropriate structure given the signature
   type.

   The ancillary field contains a structure with the TPMT_PUBLIC
   structure that contains the TPM's format of the key to be attested.
   The attestation statement data contains a hash of this structure, and
   not the key itself, so the hash of this structure needs to be
   compared to the value in the attestation attestation statement.  If
   that passes, the key needs to be transformed into a PKIX style key
   and compared to the key in the certificate signing request to
   complete the attestation verification.

   The ancillary field also contains an optional OCTET STRING which is
   used if the TPM2_Certify command is called with a non-zero length
   "qualifyingData" argument to contain that data.

   An AttestCertChain attribute MUST be present if this attribute is
   used as part of a certificate signing request.

Appendix B.  ASN.1 Module for Attestation

   The following module imports definitions from the modules defined in
   [RFC5912].

   IANA Note: Please replace TBDMOD, TBD1 and TBD2 with assigned values.

   -- This module provides a definition for two attributes thay may be
   -- used to carry key attestation information within a
   -- CertificationSigningRequest (aka PKCS10), or for other purposes.

   -- IANA - Value needed
   Attest-2023
       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-attest-01(TBDMOD) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS

   Attribute, SingleAttribute, id-pkix, Certificate
   FROM PKIX1Explicit-2009
         {iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-explicit-02(51)}

StJohns                  Expires 8 December 2023               [Page 13]
Internet-Draft         CSR Attestation Attributes              June 2023

   ATTRIBUTE,AttributeSet
   FROM PKIX-CommonTypes-2009
         {iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}

   ParamChoice
   FROM AlgorithmInformation-2009
       {iso(1) identified-organization(3) dod(6) internet(1) security(5)
       mechanisms(5) pkix(7) id-mod(0)
       id-mod-algorithmInformation-02(58)}

   -- IANA - Values needed
   -- Branch for attributes types for CSRs and related structures
   id-cra OBJECT IDENTIFIER ::= { id-pkix (TBD1) }

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

   -- A general comment is that a certificate is a signed binding between
   -- public key and some identifying info. Below "cert" is an X.509
   -- "Certificate". "opaqueCert" is just string of bytes that the
   -- receiving CA must know how to parse given information not carried
   -- in this object.  "typedCert" and "typedFlatCert" both use an OID to
   -- identify their types, but differ in that the encoding for typedCert
   -- is always valid ASN1, whereas the typedFlatCert is just a string of
   -- bytes that must be interpreted according to the type.  Note that a
   -- typedFlatCert MAY contain an encapsulated ASN1 object, but this is
   -- not the best use of the type and is hereby discouraged.
   --

   CertificateChoice ::=
      CHOICE {
         cert Certificate, -- typical X.509 cert
         opaqueCert [0] IMPLICIT OCTET STRING, -- an opaque cert who's type
                                               -- is known implicitly to
                                               -- the responder
         typedCert [1] IMPLICIT TypedCert, -- a typed cert diff from X.509
                                           -- but ASN1 parseable
         typedFlatCert [2] IMPLICIT TypedFlatCert -- typed cert not ASN1 parseable
      }

   -- Cribbed from definition of CONTENT-TYPE
   -- Alternately as TypedCert ::= SingleAttribute
   --
   TYPED-CERT ::= TYPE-IDENTIFIER -- basically an object id and a matching ASN1
                                  -- structure encoded as a sequence
   CertType ::= TYPED-CERT.&id

StJohns                  Expires 8 December 2023               [Page 14]
Internet-Draft         CSR Attestation Attributes              June 2023

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

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

   -- The receiving entity is expected to be able to parse the certBody field
   -- given the value of the certType field.  This differs from TypedCert in that
   -- the contents of the certBody field are not necessarily well formed ASN1
   -- in this case the certType tells you how to parse the body of the OCTET STRING,

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

   -- A sequence of certificates used to validate an attestation chain.
   -- By convention, the first certificate in the chain is the one that
   -- contains the public key used to verify the attestation.  If the
   -- related attestStatementAttribute contains more than a single
   -- attestation, this attribute is expected to contain all of the
   -- certificates needed to validate all attestations

   id-cra-attestChainCerts OBJECT IDENTIFIER ::= { id-cra (1) }

   attestCertsAttribute ATTRIBUTE ::= {
           TYPE SEQUENCE OF CertificateChoice
           COUNTS MAX 1
           IDENTIFIED BY id-cra-attestChainCerts
       }

   -- If the signature is provided separately, the value field need not
   -- contain the signature.  Note that some attestation methods include
   -- a signature method in the part signed by the signature and some do
   -- not.

   ATTEST-STATEMENT ::= CLASS {
     &id                 OBJECT IDENTIFIER UNIQUE,
     &Type,                  -- NOT optional
     &algidPresent       ParamOptions DEFAULT absent,
     &sigPresent         ParamOptions DEFAULT absent,
     &sigType            DEFAULT OCTET STRING

StJohns                  Expires 8 December 2023               [Page 15]
Internet-Draft         CSR Attestation Attributes              June 2023

     &ancillaryPresent   ParamOptions DEFAULT absent,
     &ancillaryType      DEFAULT OCTET STRING

   } WITH SYNTAX {
     TYPE  &Type
     IDENTIFIED BY &id
     [ALGID IS &algidPresent]
     [SIGNATURE [TYPE &sigType] IS &sigPresent]
     [ANCILLARY [TYPE &ancillaryType] IS &ancillaryPresent]
   }

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

   -- An attribute that contains a attestation statement.

   id-cra-attestStatement OBJECT IDENTIFIER ::= { id-cra 2 }

   attestAttribute ATTRIBUTE ::= {
           TYPE AttestStatement
           IDENTIFIED BY id-cra-attestStatement
       }

   END

Acknowledgements

   Thanks to Russ Housley for a first and useful pass over the original
   ASN.1.  Thanks to Mike Ounsworth for not complaining too much when I
   wrote this.  Placeholder here for people who spend time reviewing the
   draft!

Author's Address

   Michael StJohns
   NthPermutation Security LLC
   Germantown, MD 20874
   United States of America
   Email: msj@nthpermutation.com

StJohns                  Expires 8 December 2023               [Page 16]