Landis+Gyr

narinder.mittal@landisgyr.com

Landis+Gyr

chris.hett@landisgyr.com

Security Independant Submission Internet-Draft EST CoAPS This document describes a manufacturer-assisted mechanism for distributing operational certification authority (CA) certificates to devices using Enrollment over Secure Transport (EST) or EST over secure CoAP (EST-coaps). The mechanism is intended for deployments in which a device is manufactured before the operational PKI and EST server trust anchors are known. The device is provisioned during manufacturing with a manufacturer trust anchor. An operational CA certificate bundle is subsequently signed by the manufacturer, or by a manufacturer-authorized signing authority, and delivered through a manufacturer-specific EST alias. The device validates the signed bundle using its manufacturer trust anchor before installing the contained CA certificates as operational trust anchors. This mechanism is limited to CA certificate bootstrap and does not change EST enrollment semantics, proof-of-possession requirements, certification authority policy, or authenticated EST operation following bootstrap.

Table of Contents

• .  Introduction
• .  Terminology
• .  Trust Model
• .  Manufacturer-Specific EST Alias
• .  Manufacturer-Signed CA Certificate Bundle
  • .  ManufacturerSignedCACerts Structure
  • .  CMS Content Requirements
  • .  Alias Binding
• .  Bootstrap Transport Layer
  • .  HTTPS Transport
  • .  CoAP Transport
• .  Client Processing Rules
• .  Server Processing Rules
• .  Denial-of-Service Considerations
• .  Security Considerations
  • .  Manufacturer Signing Key Protection
  • .  Separation of Manufacturer Signing Function
  • .  No Enrollment Before Trust Bootstrap
  • .  Cleartext Transport Risks
  • .  Replay of Old CA Certificate Responses
  • .  Alias Substitution
  • .  Operational CA Compromise or Rollover
• .  IANA Considerations

Introduction Enrollment over Secure Transport (EST), defined in , provides certificate enrollment and CA certificate retrieval over HTTPS. EST-coaps, defined in , transports EST payloads over CoAP protected by DTLS for constrained IoT environments. defines EST over secure CoAP and maps EST functions such as /cacerts, /simpleenroll, /simplereenroll, and /csrattrs to shorter EST-coaps resources such as /crts, /sen, /sren, and /att. In all of these functions, EST client is expected to authenticate the EST server before accepting EST responses. In many deployments, devices are manufactured before the operational PKI hierarchy or EST server trust anchors are known. Such devices may be provisioned only with a manufacturer trust anchor at manufacturing time. Provisioning customer-specific trust anchors after manufacturing can add operational complexity, increase the likelihood of configuration errors, and complicate shipment or deployment logistics. Although already recognizes bootstrap distribution of CA certificates and allows a client to provisionally continue a TLS handshake to retrieve /cacerts when initial server authentication fails, it relies on manual or out-of-band authorization of the returned CA certificate data. This document provides a cryptographic authorization mechanism by defining a bootstrap mechanism that allows the client to retrieve operational CA certificates from a manufacturer-specific EST alias. The response is signed in advance by the manufacturer or a manufacturer-authorized signer. The client validates the response using the manufacturer trust anchor already provisioned in the device. This extension is limited to CA certificate retrieval. It does not permit certificate enrollment, re-enrollment, server-side key generation, or CSR attribute retrieval until the client has installed and validated the operational trust anchor and can establish a normally authenticated EST or EST-coaps session. This document does not modify or . It describes a deployment mechanism that may be used to securely distribute operator CA certificates to constrained devices prior to EST enrollment.

Terminology 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. The terminology from and applies. This document additionally defines the following terms: Definitions

Term	Definition
Manufacturer Trust Anchor	A trust anchor provisioned into the EST client during manufacturing and used to validate manufacturer-signed bootstrap material.
Manufacturer Alias	An EST or EST-coaps alias associated with a manufacturer or manufacturer trust domain.
Operational Trust Anchor	A CA certificate used by the device to authenticate the operational EST server and operational PKI.
Manufacturer-Signed CA Certificate Bundle	A CA certificate response whose exact content is signed by the manufacturer or a manufacturer-authorized signer.
Bootstrap CA Certificate Retrieval	The limited retrieval operation defined by this document, used before the client can authenticate the EST server using the operational trust anchor.
Bootstrap-Only Session	A TLS or DTLS session in which normal EST server authentication has not yet succeeded and only the bootstrap CA certificate retrieval operation is permitted.

Trust Model The trust model is based on manufacturer authorization of the CA certificate response. During manufacturing:

1. The device is provisioned with a manufacturer trust anchor.
2. The manufacturer trust anchor is stored in a protected trust store.
3. The device is configured with the manufacturer alias or with a method to derive the appropriate manufacturer alias.

During deployment:

1. The deployment operator identifies the operational CA certificate set.
2. The manufacturer, or a manufacturer-authorized signing authority, creates a ManufacturerSignedCACerts object containing the bootstrap alias, validity information, and operational CA certificate bundle. The ManufacturerSignedCACerts object is signed using CMS SignedData. The EST server publishes the resulting CMS SignedData object under a manufacturer-specific EST alias.
3. The EST server does not need to perform runtime signing for bootstrap retrieval.

During bootstrap:

1. The EST client retrieves the CA certificate response from the manufacturer-specific alias.
2. The EST client validates the manufacturer signature using the manufacturer trust anchor.
3. If validation succeeds, the EST client installs the CA certificate set as operational trust anchors.
4. The EST client establishes a new authenticated EST or EST-coaps session using the installed operational trust anchors.

Manufacturer-Specific EST Alias The EST server SHALL expose a manufacturer-specific alias for bootstrap CA certificate retrieval. For EST over HTTPS, the alias MAY use the following form: /.well-known/est/{manufacturer-alias}/cacerts For EST-coaps, the corresponding short operation SHOULD use the EST-coaps /crts function under the manufacturer alias: coaps://est.example.com/.well-known/est/{manufacturer-alias}/crts defines EST-coaps resource mappings, including the shorter /crts resource for CA certificate retrieval. The manufacturer alias identifies the manufacturer trust domain under which the response signature is validated. The manufacturer alias MUST be provisioned into the device during manufacturing or derived using a manufacturer-defined mechanism. The alias alone MUST NOT be treated as authorization to install the returned CA certificates. Authorization is established only through successful validation of the CMS signature chain to a trusted Manufacturer Trust Anchor and successful completion of all validation requirements specified in this document. A deployment MAY derive the manufacturer-specific EST alias from the manufacturer's IANA Private Enterprise Number (PEN). For example: /.well-known/est/mfg/{PEN} where {PEN} is the decimal representation of the manufacturer's assigned IANA Private Enterprise Number. Profiles adopting this mechanism MAY require use of this alias construction method to ensure interoperability. This document does not mandate a single alias construction method.

Manufacturer-Signed CA Certificate Bundle The EST server SHALL return the manufacturer-signed response in Cryptographic Message Syntax (CMS) format as defined by RFC . The SignedData object encapsulates a structured bootstrap object known as ManufacturerSignedCACerts. The manufacturer, or a manufacturer-authorized signing authority, signs this structure before it is published by the EST server. The EST server acts solely as a distribution point for the signed object and is not required to perform runtime signing. The client validates the CMS signature using the Manufacturer Trust Anchor provisioned during manufacturing. The client MUST successfully validate the CMS signature and all associated processing rules defined in this document before installing any returned CA certificates as operational trust anchors.

ManufacturerSignedCACerts Structure The CMS SignedData object SHALL encapsulate a ManufacturerSignedCACerts structure. ManufacturerSignedCACerts ::= SEQUENCE { version INTEGER (1..MAX), alias UTF8String, sequenceNumber INTEGER (0..MAX), notBefore GeneralizedTime, notAfter GeneralizedTime, caCertificates SEQUENCE SIZE (1..MAX) OF Certificate } The fields have the following meanings: version: Identifies the version of the ManufacturerSignedCACerts structure. alias: Identifies the bootstrap alias associated with the CA certificate bundle. sequenceNumber: An increasing value used by the client to detect replay and rollback attacks. notBefore: The beginning of the validity interval for the signed bundle. notAfter: The end of the validity interval for the signed bundle. caCertificates: The operational CA certificate bundle intended for installation by the EST client.

CMS Content Requirements The CMS SignedData object SHALL include:

• A signature over the complete ManufacturerSignedCACerts structure.
• The manufacturer signing certificate.
• Any intermediate certificates required to build a certification path to the Manufacturer Trust Anchor.
• CMS signed attributes required to validate the signed content.

The manufacturer signing certificate SHALL chain to a Manufacturer Trust Anchor provisioned in the device. The signer certificate SHOULD contain key usage and certificate policy information appropriate for bootstrap CA certificate response signing. The CMS SignedData object SHALL be conveyed using the "application/pkcs7-mime" media type defined for CMS objects.

Alias Binding The alias field contained within the ManufacturerSignedCACerts structure is protected by the CMS signature. The client MUST verify that the alias contained in the signed structure matches the alias associated with the bootstrap request. If the alias values do not match, the client MUST reject the response and MUST NOT install any returned CA certificates. This validation prevents substitution of a valid manufacturer-signed bundle from one bootstrap alias into another alias context.

Bootstrap Transport Layer A client that does not yet possess the operational trust anchor may be unable to authenticate the EST server certificate during TLS or DTLS server authentication. In that case, the client MUST NOT perform general EST operations. The client MAY perform only the bootstrap CA certificate retrieval operation defined by this document. Until the manufacturer signature has been validated and the operational trust anchor has been installed, the client MUST treat the transport as unauthenticated for EST authorization purposes. The TLS or DTLS connection provides transport services only and MUST NOT be interpreted as establishing server identity or authorization for any EST operation other than bootstrap CA certificate retrieval.

HTTPS Transport For EST over HTTPS, the client MAY establish a TLS connection even when the EST server certificate cannot be validated against the client's current trust anchor store, but only for retrieving the manufacturer-signed CA certificate bundle. The client MUST NOT send certificate enrollment requests, CSRs, client credentials, long-term identifiers, or sensitive information over such a connection. The client MUST validate the manufacturer signature over the CA certificate response before installing any returned CA certificate. After the manufacturer signature is validated and the operational CA certificates are installed, the client MUST establish a new TLS session and perform normal EST server authentication before performing any non-bootstrap EST operation.

CoAP Transport For EST-coaps, the client has two deployment options:

1. CoAP over DTLS with unauthenticated server certificate during bootstrap
   • The client establishes DTLS to the EST-coaps server.
   • The server may present its operational certificate.
   • The client records that the DTLS server authentication has not yet been validated.
   • The client sends only the bootstrap /crts request.
   • The client validates the manufacturer signature before accepting the returned CA certificates.
   The unauthenticated TLS/DTLS connection provides transport services only and MUST NOT be interpreted as establishing server identity.
2. CoAP without DTLS for bootstrap-only retrieval
   • The client retrieves only the manufacturer-signed CA certificate bundle.
   • Integrity and origin authentication are provided by the manufacturer CMS signature, not by the transport.
   • This mode MUST NOT be used for enrollment, re-enrollment, CSR attributes, server-side key generation, or any operation that exposes sensitive client information.

The first option is RECOMMENDED when feasible because it provides confidentiality against passive observers, although it does not provide full server authentication until the operational trust anchor is installed. The second option MAY be used where DTLS cannot be established before operational trust is available, provided that the response is public bootstrap material and the client validates the manufacturer signature before installation.

Client Processing Rules The client MUST process the response as follows:

1. Retrieve the CMS SignedData certificate response from the manufacturer-specific alias.
2. Build a certification path from the manufacturer signing certificate to the locally configured manufacturer trust anchor.
3. Verify that the manufacturer signing certificate is authorized for bootstrap CA certificate response signing.
4. Verify the CMS signature over the exact CA certificate response body.
5. If validation succeeds, install the CA certificates into the operational trust anchor store.
6. If validation fails, discard the CA certificates and log the failure.

The client MUST NOT install CA certificates unless the manufacturer signature validates successfully. The client MUST NOT use the retrieved CA certificates for certificate enrollment until they have been installed as operational trust anchors and used to authenticate a new EST or EST-coaps session.

Server Processing Rules The EST server SHALL publish only manufacturer-approved CA certificate responses under the manufacturer-specific alias. The EST server MAY serve the same static manufacturer-signed object to all devices of the corresponding manufacturer trust domain. The EST server MUST NOT dynamically generate manufacturer signatures unless it possesses an authorized manufacturer signing credential or has access to a manufacturer-approved signing service. The EST server MAY serve the bootstrap response as a cacheable object when deployment policy allows.

Denial-of-Service Considerations Bootstrap CA certificate retrieval may occur before normal EST server authentication is available. Therefore, the EST server MUST be designed to resist unauthenticated requests. The server SHOULD apply the following protections:

1. Serve bootstrap CA certificate responses as static or precomputed objects.
2. Avoid per-client database lookups for unauthenticated bootstrap requests.
3. Avoid dynamic signing during request processing.
4. Rate limit requests per source address, network prefix, manufacturer alias, and server instance.
5. Use DTLS cookies or stateless retry mechanisms where DTLS is used.
6. Limit the set of methods allowed on bootstrap aliases to GET only.
7. Reject enrollment, re-enrollment, CSR attributes, and server-side key generation requests on bootstrap-only aliases.
8. Use CoAP Block-Wise Transfer carefully so that block state does not create unbounded server memory usage.
9. Apply response-size limits and amplification controls.
10. Log abnormal request rates and repeated invalid alias requests.
11. Allow operators to disable or throttle manufacturer aliases independently.

Security Considerations

Manufacturer Signing Key Protection The manufacturer signing private key is security critical. Compromise of this key could allow an attacker to create unauthorized CA certificate responses that devices may install as operational trust anchors. The manufacturer signing key SHOULD be protected using a Hardware Security Module (HSM), Key Management System (KMS), or equivalent protected environment. The key SHOULD be generated and stored according to manufacturer key management policy and protected against unauthorized export. Loss of control of the manufacturer signing key can compromise the security of all devices that trust the corresponding Manufacturer Trust Anchor.

Separation of Manufacturer Signing Function The manufacturer signing certificate SHOULD be dedicated to bootstrap CA certificate response signing. It SHOULD NOT be reused for TLS server authentication, CA certificate issuance, firmware signing, or other unrelated purposes. Separation of duties reduces the impact of compromise of any individual key and simplifies authorization policy within the client.

No Enrollment Before Trust Bootstrap The client MUST complete manufacturer signature validation and operational trust anchor installation before initiating any EST operation over a new TLS or DTLS transport. This ensures that all non-bootstrap EST operations continue to rely on authenticated server communication.

Cleartext Transport Risks The manufacturer CMS signature provides integrity and origin authentication for the CA certificate response. If Cleartext HTTP or CoAP is used, it exposes the alias and the signed CA certificate bundle to passive observers. This is acceptable only if the bootstrap CA certificate response is considered public deployment metadata. Deployments that require confidentiality for the manufacturer alias and CA certificate bundle SHOULD use TLS or DTLS. Cleartext transport MUST NOT be used for credential exchange, enrollment requests, client authentication, or any operation involving sensitive client information.

Replay of Old CA Certificate Responses A validly signed but old CA certificate bundle might be replayed by an attacker. To mitigate these attacks, the signed response SHOULD include validity information such as a sequence number, version information, or signing time. Clients SHOULD store the highest accepted sequence number or version for each alias and SHOULD reject older bundles. If the client possesses a reliable source of time, the client MUST verify that the current time falls within the validity interval defined by notBefore and notAfter. If reliable time is unavailable, the client MAY defer validity interval verification and rely on sequenceNumber-based freshness validation. Once authenticated time is available, the client SHOULD verify the validity interval and apply local policy if the bundle falls outside the defined validity period.

Alias Substitution An attacker might attempt to substitute a signed object intended for one alias into the response for another alias. To prevent this, the alias MUST be included in the CMS-protected content. The client MUST verify that the protected alias matches the requested alias or an equivalent locally configured alias.

Operational CA Compromise or Rollover This mechanism can be used to distribute replacement operational trust anchors following operational CA rollover, CA expiration, CA compromise, or other trust-anchor transition events. A manufacturer-signed bundle may contain new operational CA certificates, replacement operational CA certificates, or a complete replacement trust-anchor set. Clients MUST apply local trust-anchor management policy when processing a newly validated bundle. Deployments that permit trust-anchor replacement through manufacturer-signed bundles SHOULD ensure that sequence number processing prevents rollback to previously accepted trust-anchor sets. A successfully validated manufacturer-signed bundle MAY update, replace, or augment existing operational trust anchors in accordance with local policy and without requiring out-of-band authorization.

IANA Considerations This document does not define any new protocol message types, URI schemes, CoAP methods, HTTP methods, TLS extensions, DTLS extensions, certificate extensions, or registries. The manufacturer alias defined by this document is represented as part of the EST or EST-coaps URI path and is not an IANA-registered parameter. No IANA actions are required by 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. This document describes the Cryptographic Message Syntax (CMS). CMS provides a general syntax for protecting data with digital signatures, message authentication codes, and encryption. 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. 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. Consultant Cisco Systems Sandelman Software Works RISE Research Institutes of Sweden Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.

Operational Scenario Example This section expands on the Operational Scenario Overviews by providing detailed examples of the messages. This appendix is informative and provided only as an example.

Obtaining CA certificates with embedded manufacturer trust The following is an example of a valid /cacerts with manufacturer alias GET /.well-known/est/{manufacturer-alias}/cacerts HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 192.0.2.1:8085 Accept: */* In response, server provides the response: HTTP/1.1 200 OK Status: 200 OK Content-Type: application/cms Content-Transfer-Encoding: base64 Content-Length: 647 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggFOMIIBSjCB8aADAgECAgEBMAoGCCqGSM49BAMCMB4xHDAJBgNVBAYTAlJV MA8GA1UEAx4IAFQAZQBzAHQwHhcNMjMwNzE4MjAwNzE0WhcNMjQwNzE4MjAwNzE0 WjAeMRwwCQYDVQQGEwJSVTAPBgNVBAMeCABUAGUAcwB0MFkwEwYHKoZIzj0CAQYI KoZIzj0DAQcDQgAEr13czVhlDbc3Y3o/sYXvEWBxVIjEqMWQwo8eSvwJxkb5dZoV qoOcwoVYQ2ADq7+hpbzcosYF3Zm/fYUY//RV9qMgMB4wDwYDVR0TBAgwBgEB/wIB AzALBgNVHQ8EBAMCAAYwCgYIKoZIzj0EAwIDSAAwRQIhAPbH2ODIYTya2rRP6vz8 KERaH5Lro84ImJbePBzxRqd3AiBWWFI7bvNy9MtsWH/wDM9360E7vtRUdNvW0L7a Z72O7jGB+jCB9wIBATAjMB4xHDAJBgNVBAYTAlJVMA8GA1UEAx4IAFQAZQBzAHQC AQEwDQYJYIZIAWUDBAIBBQCgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0yMzA3MTgyMDA3MTRaMC8GCSqGSIb3DQEJBDEiBCCN5SFU PprUlKgWp/V/CxMLKKHU1mjtY/WttBvrXTN8DjAKBggqhkjOPQQDAgRHMEUCICRg kFOpxXsJIuKk8IQapP6tRweZmV7s8AZ3rXeW3wYsAiEArysc8vCTt6jFbXvdv72m T261hpld0ggKQEVbJ+ePjv8AAAAAAAA= Response content structure in CMS Format: ContentInfo { contentType id-signedData, //(Value = 1.2.840.113549.1.7.2) content SignedData } SignedData { version CMSVersion, (Value = 3) digestAlgorithms SET OF DigestAlgorithmIdentifier, //(Value = 2.16.840.1.101.3.4.2.1) encapContentInfo EncapsulatedContentInfo, certificates CertificateSet, //(Manufacturer Signing Certificate with Full Chain) crls CertificateRevocationLists, //(Optional) signerInfos SET OF SignerInfo } SignerInfo { version CMSVersion, //(Value = 3) sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, //(Value = 2.16.840.1.101.3.4.2.1) signedAttrs SignedAttributes, signatureAlgorithm SignatureAlgorithmIdentifier, //(Value = 1.2.840.10045.4.3.2) signature SignatureValue, unsignedAttrs UnsignedAttributes //(Optional) } SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier //(Preferred to Use) } SignedAttributes ::= SET SIZE (1..MAX) OF Attribute // (Sample Paramterse // ContentType - 1.2.840.113549.1.9.3 // MessageDigest - 1.2.840.113549.1.9.4 // SigningTime - 1.2.840.113549.1.9.5 // ) Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY EncapsulatedContentInfo ::= SEQUENCE { eContentType id-data, eContent [0] EXPLICIT OCTET STRING //ManufacturerSignedCACerts content } ManufacturerSignedCACerts ::= SEQUENCE { version INTEGER, alias UTF8String, sequenceNumber INTEGER, notBefore GeneralizedTime, notAfter GeneralizedTime, caCertificates SEQUENCE SIZE (1..MAX) OF Certificate }

Authors' Addresses Landis+Gyr

narinder.mittal@landisgyr.com

Landis+Gyr

chris.hett@landisgyr.com