]> Siemens

hannes.tschofenig@siemens.com

Siemens

hendrik.brockhaus@siemens.com

Security LAMPS Internet-Draft Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) define protocol messages for X.509v3 certificate creation and management. Both protocol provide interactions between client systems and PKI management entities, such as a Registration Authority (RA) and a Certification Authority (CA). CMP and EST allow an RA/CA to request additional information it has to provide in a certification request. When an end entity places attestation Evidence in a Certificate Signing Request (CSR) it may need to demonstrate freshness of the provided Evidence. Attestation technology today often accomplishes this task via the help of nonces. This document specifies how nonces are provided by an RA/CA to the end entity for inclusion in Evidence.

Introduction Several protocols have been standardized to automate the management of certificates, such as certificate issuance, CA certificate provisioning, certificate renewal and certificate revocation. The Certificate Management Protocol (CMP) defines protocol messages for X.509v3 certificate creation and management. CMP provides interactions between end entities and PKI components, such as a Registration Authority (RA) and a Certification Authority (CA). Enrollment over Secure Transport (EST) is another certificate management protocol, which provides a sub-set of the features offered by CMP. An end entity 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, and claims about the platform itself. To convey these claims in Evidence, as part of remote attestation, the remote attestation extension has been defined. It describes how to encode Evidence produced by an Attester for inclusion in Certificate Signing Requests (CSRs), and any certificates necessary for validating it. A Verifier or Relying Party might need to learn the point in time an Evidence has been produced. This is essential in deciding whether the included Claims can be considered fresh, meaning they still reflect the latest state of the Attester. Attestation technology available today, such as and , often accomplish freshness with the help of nonces. More details about ensuring freshness of Evidence can be found in Section 10 of . Since an end entity needs to obtain a nonce from the Verifier via the Relying Party, this leads to an additional roundtrip. The CSR is, however, a one-shot message. For this reason CMP and EST are used by the end entity to obtain the nonce from the RA/CA. CMP and EST conveniently offer a mechanism to request information from the RA/CA prior to a certification request. Once the nonce is obtained the end entity can issue an API call to the Attester to request Evidence and passes the nonce as an input parameter into the API call. The returned Evidence is then embedded into a CSR and returned to the RA/CA in a certification request message. shows this interaction graphically. The nonce is obtained in step (1) using the extension to CMP/EST defined in this document. The CSR extension of is used to convey Evidence to the RA/CA in step (2). The Verifier processes the received information and returns an Attestation Result to the Relying Party in step (3).

|---------' | | | | Evidence | Relying | | v | in CSR | Party (RA/CA) | | Attester | (2) | | | | | | '------------' '---------------' ]]>

The functionality of this document is described in two sections, namely: describes how to convey the nonce CMP, and offers the equivalent functionality for EST.

Terminology and 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 . The terms Attester, Relying Party, Verifier and Evidence are defined in . The terms end entity, certification authority (CA), and registration authority (RA) are defined in . We use the terms Certificate Signing Request (CSR) and certification request interchangeably.

Conveying a Nonce in CMP Section 5.3.19.16 of defines the general request message (genm) and general response (genp). The NonceRequest payload of the genm message, which is send by the end entity to request a nonce, contains optional details on the length of nonce the Attester requires. The NonceResponse payload of the genp message, which is sent by the CA/RA in response to a request message by the end entity, contains the nonce.

id-it-NonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 } NonceRequestValue ::= SEQUENCE { len INTEGER OPTIONAL, -- indicates the required length of the requested nonce hint EvidenceHint OPTIONAL -- indicates which Verifier to request a nonce from } id-it-NonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 } NonceResponseValue ::= SEQUENCE { nonce OCTET STRING -- contains the nonce of length len -- provided by the Verifier indicated with hint expiry Time OPTIONAL -- indicates how long the Verifier considers the -- nonce valid } ]]>

Note: The EvidenceHint structure is defined in . The hint is intended for an Attester to indicate to the EST server which Verifier should be invoked to request a nonce. The use of the general request/response message exchange leads to an extra roundtrip to convey the nonce from the CA/RA to the end entity (and ultimately to the Attester inside the end entity). The end entity MUST construct a NonceRequest request message to trigger the RA/CA to transmit a nonce in the response. [Open Issue: Should request message indicate the remote attestation capability of the end entity rather than relying on "policy information"? This may also allow to inform the CA/RA about the type of attestation technology/technologies available to the end entity.] If the end entity supports remote attestation and the policy requires Evidence in a CSR to be provided, the RA/CA issues an NonceResponse response message containing a nonce. showns the interaction graphically.

>-- NonceRequest -->>-- Verify request Generate nonce* Create response --<<-- NonceResponse --<<-- (nonce, expiry) Generate key pair Generate Evidence* Generate certification request message -->>-- certification request -->>-- (+Evidence including nonce) Verify request Verify Evidence* Check for replay* Issue certificate Create response --<<-- certification response --<<-- Handle response Store certificate *: These steps require interactions with the Attester (on the EE side) and with the Verifier (on the RA/CA side). ]]>

Conveying a Nonce in EST The EST client can request a nonce for its Attester. This function is generally performed after requesting CA certificates and before other EST functions. The EST server MUST support the use of the path-prefix of "/.well- known/" as defined in and the registered name of "est". Thus, a valid EST server URI path begins with "https://www.example.com/.well-known/est". Each EST operation is indicated by a path-suffix that indicates the intended operation. The following operation is defined by this specificaion:

The operation path is appended to the path-prefix to form the URI used with HTTP GET or POST to perform the desired EST operation. An example valid URI absolute path for the "/nonce" operation is "/.well-known/est/nonce". An EST client uses a GET or a POST depending on whether parameters are included: A GET request MUST be used when the EST client does not want to convey extra parameters. A POST request MUST be used when parameters, like nonce length or a hint about the verification service, are included in the request.

To retrieve a nonce using a GET, the EST client would use the following HTTP request-line:

To retrieve a nonce by specifying the size of the requested nonce (and/or by including a hint about the Verification service) a POST message is used, as shown below:

The payload in a POST request MUST be of content-type of "application/json" and MUST contain a JSON object with the member "len" and/or "hint". The value of the "len" member indicates the length of the requested nonce value in bytes. The "hint" member contains either be a rfc822Name, a dNSName, a uri, or a test value (based on the definition in the EvidenceHint structure from ). The EST server MAY request HTTP-based client authentication, as explained in Section 3.2.3 of . If the request is successful, the EST server response MUST contain a HTTP 200 response code with a content-type of "application/json" and a JSON object with the member nonce. The expiry member is optional and indicates the time the nonce is considered valid. After the expiry time is expired, the session is likely garbage collected. Below is a non-normative example of the response given by the EST server:

[Open Issue: Should we also register a content type for use with EST over CoAP where the nonce and the expiry field is encoded in a CBOR structure?]

Nonce Processing Guidelines When the RA/CA is requested or configured to transmit a nonce to an end entity then it interacts with the Verifier. The Verifier is, according to the IETF RATS architecture , "a role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party." Since the Verifier validates Evidence it is also the source of the nonce to check for replay. The nonce value MUST contain a random byte sequence whereby the length depends on the used remote attestation technology. Since the nonce is relayed with the RA/CA, it MUST be copied to the respective structure, as described in and , for transmission to the Attester. For example, the PSA attestation token supports nonces of length 32, 48 and 64 bytes. Other attestation technologies use nonces of similar length. The assumption in this specification is that the RA/CA have out-of-band knowledge about the required nonce length required for the attestation technology used by the end entity. The nonces of incorrect length will cause the remote attestation protocol to fail. When the end entity receives the nonce it MUST use it, if remote attestation is available and supports nonces. It is better for an RA/CA to be aggressive in sending a nonce, at least where there is a reasonable chance the client supports remote attestation and the client should be allowed to ignore the nonce if it either does not support it or cannot use it for policy reasons. While the semantics of the attestation API and the software/hardware architecture is out-of-scope of this specification, the API will return Evidence from the Attester in a format specific to the attestation technology utilized. The encoding of the returned evidence varies but will be placed inside the CSR, as specified in . The software creating the CSR will not have to interpret the Evidence format - it is treated as an opaque blob. It is important to note that the nonce is carried in the Evidence, either implicitly or explicitly, and it MUST NOT be conveyed in CSR structures outside the Evidence payload. The processing of the CSR containing Evidence is described in . Note that the issued certificates does not contain the nonce, as explained in .

IANA Considerations TBD:

Security Considerations This specification defines how to obtain a nonce via CMP and EST and assumes that the nonce does not require confidentiality protection without impacting the security property of the remote attestation protocol. defines the IETF remote attestation architecture discusses nonce-based freshness in great detail. Section 8.4 of places randomness and privacy requirement on the generation of the nonce for use with an Entity Attestation Token (EAT). These requirements have been adopted by attestation technologies, such as the PSA attestation token and are of general utility: The nonce MUST have at least 64 bits of entropy. To avoid the conveyance of privacy-related information in the nonce, it should be derived using a salt that originates from a true and reliable random number generator or any other source of randomness. Since each specification of an attestation technology offers guidance for replay protection with nonces (and other techniques) this document needs to defer specific guidance to the respective specifications. For the use of Evidence in a CSR the security considerations of are relevant to this document.

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. Entrust Limited Siemens Fraunhofer SIT A PKI end entity 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 defines a new PKCS#10 attribute attr-evidence and CRMF extension ext-evidence that allows placing any Evidence data, in any pre-existing format, along with any certificates needed to validate it, into a PKCS#10 or CRMF CSR. 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). Siemens Siemens Entrust Entrust This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document obsoletes RFC 4210 by including the updates specified by CMP Updates RFC 9480 Section 2 and Appendix A.2 maintaining backward compatibility with CMP version 2 wherever possible and obsoletes both documents. Updates to CMP version 2 are: improving crypto agility, extending the polling mechanism, adding new general message types, and adding extended key usages to identify special CMP server authorizations. Introducing CMP version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue, hashAlg for indicating a hash AlgorithmIdentifier in certConf messages, and RootCaKeyUpdateContent in ckuann messages. In addition to the changes specified in CMP Updates RFC 9480 this document adds support for management of KEM certificates. The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. 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] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 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. Arm Limited Arm Limited HP Labs Linaro The Arm 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 can produce attestation tokens as described in this memo, which are the basis for many 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 profile of the 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. This informational document is published as an independent submission to improve interoperability with ARM's architecture. It is not a standard nor a product of the IETF. Security Theory LLC Mediatek USA 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. Trusted Computing Group

Acknowledgments We would like to thank Russ Housley, Thomas Fossati, Watson Ladd, Ionut Mihalcea and Carl Wallace for their review comments.