]> Siemens

hannes.tschofenig@siemens.com

Siemens

hendrik.brockhaus@siemens.com

Security LAMPS Internet-Draft Certificate Management Protocol (CMP) defines protocol messages 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). CMP allows an RA/CA to inform an end entity about the information it has to provide in a certification request. When an end entity places attestation information in form of evidence in a certification 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 Certificate Management Protocol (CMP) defines protocol messages 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). CMP allows an RA/CA to inform an end entity about the information it has to provide in a certification request. When an end entity places attestation information in form of evidence in a certification signing request (CSR) it may need to demonstrate freshness of the provided evidence. Such an attestation extension to a CSR is described in . Attestation technology today, such as and , often accomplishes this task via the help of nonces. A discussion of freshness approaches for evidence is found in Section 10 of . For an end entity to include a nonce in the evidence (by the attester) it is necessary to obtain this nonce from the relying party, i.e. RA/CA in our use case, first. Since the CSR itself is a 'one-shot' message the CMP protocol is used to obtain the nonce from the RA/CA. CMP already offers a mechanism to request information from the RA/CA prior to a certification request. This document uses the CertReqTemplate described in Section 5.3.19.16 of . 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. This exchange is shown graphically below. >-- CertReqTemplate request -->>-- Verify request Generate nonce Create response --<<-- CertReqTemplate response --<<-- (nonce) Generate key pair Fetch Evidence (with nonce) from attester Evidence Response from attestation Creation of certification request Protect request -->>-- certification request -->>-- (evidence including nonce) Verify request Verify evidence Create response --<<-- certification response --<<-- Handle response ]]>

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 . We use the terms certification signing request (CSR) and certification request interchangeably.

Certificate Request Template Extension The following structure defines the attestation nonce provided by the CA/RA via a CertReqTemplate response message. This leads to an extra roundtrip to convey the nonce to the end entity (and ultimately to the attester functionality inside the device). The end entity MUST construct a CertReqTemplate request message to trigger the RA/CA to transmit a nonce. When the RA/CA receive the CertReqTemplate request message the profile information is used to determine that the end entity supports attestation functionality. If the end-entity supports attestation and the policy requires attestation information in a CSR to be provided, the RA/CA issues a CertReqTemplate response containing a nonce in in the template. The AttestationNonce MUST contain a random value that depends on the used attestation technology. 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 technology used by the end entity. When the end entity receives the CertReqTemplate response it MUST use this nonce as input to the API call made to the attester functionality on the device. While the semantic of the API call and the software/hardware architecture is out-of-scope of this specification, it 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 either implictily or explicitly in the evidence and it MUST NOT be conveyed in elements of the CSR. The processing of the CSR containing attestation information is described in . Note that the CA MUST NOT issue a certificate that contains the extension provided in the CertReqTemplate containing the nonce. The nonce MUST only be used for determining freshness of the evidence provided by the attester. The nonce is not included in an X.509 certificate. [Editor's Note: It may be useful to augment the CertReqTemplate request with information about the type of attestation technology/technologies available on the end entity. This is a topic for further discussion.]

IANA Considerations TBD.

Security Considerations This specification adds a nonce to the Certificate Request Template for use with attestation information in a CSR. This specification assumes that the nonce does not require confidentiality protection without impacting the security property of the attestation protocol. defining the IETF remote attestation architecture discusses this and other aspects in more detail. For the use of attestation in the CSR the security considerations of are relevant to this document.

Acknowledgments Add your name here.

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. Entrust Limited Siemens Utilizing information from a device or hardware security module about its posture can help to improve security of the overall system. Information about the manufacturer of the hardware, the version of the firmware running on this hardware and potentially about the layers of software above the firmware, the presence of hardware security functionality to protect keys and many more properties can be made available to remote parties in a cryptographically secured way. This functionality is accomplished with attestation technology. This document describes extensions to encode evidence produced by an attester for inclusion in PKCS10 certificate signing requests. More specifically, two new ASN.1 Attribute definitions, and an ASN.1 CLASS definition to convey attestation information to a Registration Authority or to a Certification Authority are described. 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 [RFCAAAA] 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 version 3 to be used only for changes to the ASN.1 syntax, which are: support of EnvelopedData instead of EncryptedValue and hashAlg for indicating a hash AlgorithmIdentifier in certConf messages. In addition to the changes specified in CMP Updates [RFCAAAA] this document adds support for management of KEM certificates. Informative References 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 Arm Limited 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. Trusted Computing Group