X.509-based Attestation Evidence

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 25 April 2024.¶

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

Table of Contents

1. Introduction

Trusted execution environments, like secure elements and hardware security modules, are now widely used, which provide a safe environment to place security sensitive code, such as cryptography, secure boot, secure storage, and other essential security functions. These security functions are typically exposed through a narrow and well-defined interface, and can be used by operating system libraries and applications.¶

When a Certificate Signing Request (CSR) library is requesting a certificate from a Certification Authority (CA), a PKI end entity may wish to provide Evidence of the security properties of the trusted execution environment in which the private key is stored. This Evidence is to be verified by a Relying Party, such as the Registration Authority or the Certification Authority as part of validating an incoming CSR against a given certificate policy. [I-D.ietf-lamps-csr-attestation] defines how to carry Evidence in either PKCS#10 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211].¶

[I-D.ietf-lamps-csr-attestation] is agnostic to the content and the encoding of Evidence. To offer interoperability it is necessary to define a format that is utilized in a specific deployment environment environment. Hardware security modules and other trusted execution environments, which have been using ASN.1-based encodings for a long time prefer the use of the same format throughout their software ecosystem. For those use cases this specification has been developed.¶

This specification re-uses the claims defined in [I-D.ietf-rats-eat], and encodes them as an extension in an X.509 certificate [RFC5280]. While the encoding of the claims is different to what is defined in [I-D.ietf-rats-eat], the semantics of the claims is retained. This specification is not an EAP profile, as defined in Section 6 of [I-D.ietf-rats-eat]¶

This specification was designed to meet the requirements published by the CA Browser Forum to convey properties about hardware security models, such as non-exportability, which must be enabled for storing publicly-trusted code-signing keys. Hence, this specification is supposed to be used with the attestation extension for Certificate Signing Requests (CSRs), see [I-D.ietf-lamps-csr-attestation], but Evidence encoded as X.509 certificates may also be used in other context.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document re-uses the terms defined in [RFC9334] related to remote attestation. Readers of this document are assumed to be familiar with the following terms: Evidence, Claim, Attestation Result, Attester, Verifier, and Relying Party.¶

3. Claims

   id-ce-evidence-nonce OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_nonce }

   claim_nonce ::= OCTET STRING

   id-ce-evidence-ueid OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_ueid }

   claim_ueid ::= SEQUENCE {
       type    INTEGER ( RAND(1), EUI(2), IMEI(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-sueids OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_sueids }

   claim_sueids ::= SEQUENCE {
       label   OCTET STRING,
       type    INTEGER ( RAND(1), EUI(2), IMEI(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-oemid OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_oemid }

   claim_oemid ::= SEQUENCE {
       type    INTEGER ( PEN(1), IEEE(2), RANDOM(3),...),
       value   OCTET STRING
   }

   id-ce-evidence-hwmodel OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_hwmodel }

   claim_hwmodel ::= OCTET STRING

   id-ce-evidence-hwversion OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_hwwversion }

   hwversion ::= OCTET STRING

   id-ce-evidence-swversion OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_swversion }

   swversion ::= PrintableString

   id-ce-evidence-dbgstat OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_dbgstat }

   dbgstat ::= ENUMERATED {
      dsEnabled                   (0),
      disabled                    (1),
      disabledSinceBoot           (2),
      disabledPermanently         (3),
      disabledFullyAndPermanently (4)
   }

   id-ce-evidence-softwarecomponent OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_softwarecomponent }

   softwarecomponent ::= SEQUENCE {
       measurement-type    PrintableString,
       measurement-value   OCTET STRING,
       signer-id           OCTET STRING,
       measurement-desc    OBJECT IDENTIFIER
   }

   softwarecomponents  ::=  SEQUENCE SIZE (1..MAX)
                            OF softwarecomponent

   id-ce-evidence-fips_conf OBJECT IDENTIFIER ::=
         { id-ce TBD_evidence TBD_fips_conf }

   fipsconf ::= SEQUENCE {
       fipsconf    BOOLEAN
   }

4. Security Considerations

This specification re-uses the claims from the EAT specification but relies on the security protection offered by X.509 certificate and particularly the digital signature covering the certificate. This digital signature is computed with the Attestation Key available on the device, see Section 12.1 of [RFC9334] for considerations regarding the generation, the use and the protection of these Attestation Keys. Although the encoding of an X.509 certificate has been selected for conveying Claims from an Attester to a Relying Party, this document uses a model that is very different from Web PKI deployment where CAs verify whether an applicant for a certificate legitimately represents the domain name(s) in the certificate. Since the Attester located at the end entity creates the X.509 certificate with claims defined in this document, it conceptually acts like a CA. This document inherits the remote attestation architecture described in [RFC9334]. With the re-use of the claims from [I-D.ietf-rats-eat] the security and privacy considerations apply also to this document even though the encoding in this specification is different from the encoding of claims discussed by [I-D.ietf-rats-eat].¶

Evidence contains information that may be unique to a device and may therefore allow to single out an individual device for tracking purposes. Deployments that have privacy requirements must take appropriate measures to ensure that claim values can only identify a group of devices and that the Attestation Keys are used across a number of devices as well.¶

To verify the Evidence, the primary need is to check the signature and the correct encoding of the claims. To produce the Attestation Result, the Verifier will use Endorsements, Reference Values, and Appraisal Policies. The policies may require that certain claims must be present and that their values match registered reference values. All claims may be worthy of additional appraisal.¶

5. IANA Considerations

TBD: OIDs for all the claims listed in this document.¶

Appendix A. Acknowledgements

This specification is the work of a design team created by the chairs of the LAMPS working group. This specification has been developed based on discussions in that design team.¶

The following persons, in no specific order, contributed to the work: Richard Kettlewell, Chris Trufan, Bruno Couillard, Jean-Pierre Fiset, Sander Temme, Jethro Beekman, Zsolt Rózsahegyi, Ferenc Pető, Mike Agrenius Kushner, Tomas Gustavsson, Dieter Bong, Christopher Meyer, Michael StJohns, Carl Wallace, Michael Ricardson, Tomofumi Okubo, Olivier Couillard, John Gray, Eric Amador, Johnson Darren, Herman Slatman, Tiru Reddy, Thomas Fossati, Corey Bonnel, Argenius Kushner, James Hagborg.¶

Appendix B. Full ASN.1

TBD: Full ASN.1 goes in here.¶

Authors' Addresses