Attestation Attributes for use with Certificate Requests
draft-stjohns-csr-attest-00

LAMPS                                                         M. StJohns
Internet-Draft                               NthPermutation Security LLC
Intended status: Informational                                5 May 2023
Expires: 6 November 2023

        Attestation Attributes for use with Certificate Requests
                      draft-stjohns-csr-attest-00

Abstract

   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 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 6 November 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 6 November 2023                [Page 1]
Internet-Draft         CSR Attestation Attributes               May 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  ASN.1 Elements  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Object Identifiers  . . . . . . . . . . . . . . . . . . .   3
     2.2.  CertificateChoice . . . . . . . . . . . . . . . . . . . .   3
     2.3.  AttestAttribute . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  AttestCertsAttribute  . . . . . . . . . . . . . . . . . .   4
     2.5.  AttestStatement . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  SignatureChoice . . . . . . . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   7
     A.1.  Sample TPM V2.0 Attestation Attribute . . . . . . . . . .   7
   Appendix B.  ASN.1 Module for Attestation . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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

StJohns                  Expires 6 November 2023                [Page 2]
Internet-Draft         CSR Attestation Attributes               May 2023

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.

StJohns                  Expires 6 November 2023                [Page 3]
Internet-Draft         CSR Attestation Attributes               May 2023

           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.

StJohns                  Expires 6 November 2023                [Page 4]
Internet-Draft         CSR Attestation Attributes               May 2023

           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.

StJohns                  Expires 6 November 2023                [Page 5]
Internet-Draft         CSR Attestation Attributes               May 2023

   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
           }

3.  IANA Considerations

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

4.  Security Considerations

   TBD

5.  References

5.1.  Normative References

StJohns                  Expires 6 November 2023                [Page 6]
Internet-Draft         CSR Attestation Attributes               May 2023

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

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

StJohns                  Expires 6 November 2023                [Page 7]
Internet-Draft         CSR Attestation Attributes               May 2023

   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
   Email: msj@nthpermutation.com

StJohns                  Expires 6 November 2023                [Page 8]