]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Siemens

hannes.tschofenig@gmx.net

Security RATS Internet-Draft This document specifies Claims for use within X.509 certificates. These X.509 certificates are produced by an Attester as part of the remote attestation procedures and consitute Evidence. This document follows the Remote ATtestation procedureS (RATS) architecture where Evidence is sent by an Attester and processed by a Verifier. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

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. defines how to carry Evidence in either PKCS#10 or Certificate Request Message Format (CRMF) . 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 , and encodes them as an extension in an X.509 certificate . While the encoding of the claims is different to what is defined in , the semantics of the claims is retained. This specification is not an EAP profile, as defined in Section 6 of 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 , but Evidence encoded as X.509 certificates may also be used in other context.

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 when, and only when, they appear in all capitals, as shown here. This document re-uses the terms defined in 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.

Claims

Nonce The "nonce" claim is used to provide freshness. The Nonce claim is used to carry the challenge provided by the caller to demonstrate freshness of the generated token. The following constraints apply to the nonce-type:

• The length MUST be either 32, 48, or 64 bytes.
• Only a single nonce value is conveyed.

The nonce claim is defined as follows: See Section 4.1 of for a description of this claim.

ueid (Universal Entity ID) Claim The "ueid" claim conveys a UEID, which identifies an individual manufactured entity. This identifier is a globally unique and permanent identifier. See Section 4.2.1 of for a description of this claim. Three types of UEIDs are defined, which are distinguished via a type field. The ueid claim is defined as follows:

sueids (Semi-permanent UEIDs) Claim (SUEIDs) The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs). An SUEID has the same format, characteristics and requirements as a UEID, but MAY change to a different value on entity life-cycle events while the ueid claim is permanent. An entity MAY have both a UEID and SUEIDs, neither, one or the other. There MAY be multiple SUEIDs and each has a text string label the purpose of which is to distinguish it from others. See Section 4.2.2 of for a description of this claim. The sueids claim is defined as follows:

oemid (Hardware OEM Identification) Claim The "oemid" claim identifies the Original Equipment Manufacturer (OEM) of the hardware. See Section 4.2.3 of for a description of this claim. The value of this claim depends on the type of OEMID and three types of IDs are defined:

• OEMIDs using a 128-bit random number. Section 4.2.3.1 of defines this type.
• an IEEE based OEMID using a global registry for MAC addresses and company IDs. Section 4.2.3.1 of defines this type.
• OEMIDs using Private Enterprise Numbers maintained by IANA. Section 4.2.3.3 of defines this type.

The oemid claim is defined as follows: [Editor's Note: The value for the PEN is numeric. For the other two types it is a binary string.]

hwmodel (Hardware Model) Claim The "hwmodel" claim differentiates hardware models, products and variants manufactured by a particular OEM, the one identified by OEM ID. It MUST be unique within a given OEM ID. The concatenation of the OEM ID and "hwmodel" give a global identifier of a particular product. The "hwmodel" claim MUST only be present if an "oemid" claim is present. See Section 4.2.4 of for a description of this claim. The hwmodel claim is defined as follows:

hwversion (Hardware Version) Claim The "hwversion" claim is a text string the format of which is set by each manufacturer. A "hwversion" claim MUST only be present if a "hwmodel" claim is present. See Section 4.2.5 of for a description of this claim. The hwversion claim is defined as follows:

swversion (Software Version) Claim The "swversion" claim makes use of the CoSWID version-scheme defined in Section 4.1 of to give a simple version for the software. A "swversion" claim MUST only be present if a "swname" claim is present. See Section 4.2.5 of for a description of this claim. The swversion claim is defined as follows:

dbgstat (Debug Status) Claim The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities and diagnostic hardware built into chips. It applies to any software debug facilities related to privileged software that allows system-wide memory inspection, tracing or modification of non-system software like user mode applications. See Section 4.2.9 of for a description of this claim and the semantic of the values in the enumerated list. The dbgstat claim is defined as follows:

software-component Claim The Software Components claim is a list of software components that includes all the software (both code and configuration) loaded by the root of trust. Each entry in the Software Components list describes one software component using the attributes described below:

• The Measurement Type attribute is short string representing the role of this software component. Examples include the bootloader code, the bootloader configuration, and firmware running in the Trusted Execution Environment.
• The Measurement Value attribute represents a hash of the invariant software component in memory at startup time. The value MUST be a cryptographic hash of 256 bits or stronger. For interoperability, SHA-256 is assumed to be the default.
• The Signer ID attribute is the hash of a signing authority public key for the software component. This can be used by a Verifier to ensure the components were signed by an expected trusted source.
• The Measurement Description contains the OID identifying the hash algorithm used to compute the corresponding Measurement Value. For interoperability, SHA-256 is the default. If the default algorithm is used, then this field can be omitted. The values for identifying the hash algorithms MUST be taken from .

The description of the software-component claims is taken from Section 4.4.1 of The software-component claim is defined as follows:

fips_conf (Federal Information Processing Standards Conformance) Claim The "fips_conf" claim applies to entity-wide or submodule-wide cryptographic modules and attests whether the cryptographic module is running in FIPS mode. A cryptographic module cannot, in general, know whether it has a valid FIPS certification, but it does know whether it is running in FIPS mode. The FIPS conformance claim is defined as follows: TBD: Perhaps there is more data that needs to be here? Such as, the device may need to attest the Security Policy under which it is currently operating since for example a FIPS 140-2 Level 2 security policy might be different from a 140-3 Level 4. This sounds like we would need either a vendor-defined string known to the verifier, or an ENUMERATED list of "FIPS 140-{2,3} Level {1,2,3,4}" which will be an evolving list. Neither sounds clean. Needs more discussion. TBD: Tomas to review and add to this text.

cc_conf (Common Criteria Conformance) Claim TBD: Is there a CC equivalent of the fips_conf claim? There might not be any value to having this claim. Need review by people more expert in CC than me.

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 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 . With the re-use of the claims from 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 . 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.

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] Arm Limited Arm Limited HP Labs Linaro The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profiled Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. Entrust Limited Siemens Fraunhofer SIT A client requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document describes how to encode Evidence produced by an Attester for inclusion in Certificate Signing Requests (CSRs), and any certificates necessary for validating it. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). IANA

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.

Full ASN.1 TBD: Full ASN.1 goes in here.