Network Working Group N. Mittal Internet-Draft C. Hett Intended status: Informational Landis+Gyr Expires: 12 April 2027 October 2026 EST-coaps Enrollment Using Device-Unique Symmetric Keys for Field Devices without Initial Certificates draft-mittal-est-coap-no-cert-00 Abstract This document specifies a profile for Enrollment over Secure Transport using secure CoAP, where the EST-coaps client is a field device that does not possess an initial device certificate, manufacturer certificate, or other certificates usable for DTLS client authentication. Instead, the device is authenticated during the DTLS handshake using a device-unique symmetric key or a pre- shared key derived from that device-unique key. This profile is intended for already registered and operational devices that do not possess a certificate suitable for EST-coaps client authentication but do possess a device-unique symmetric key that can be used for initial authentication during certificate enrollment. The mechanism preserves EST certificate enrollment semantics while replacing the initial certificate-based DTLS client authentication requirement with PSK-based DTLS authentication. [RFC9148] defines EST over secure CoAP and requires client authentication for EST-coaps functions, while [RFC7030] permits certificate-less TLS authentication scenarios for EST when suitable shared credentials are available. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 3.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 5 4. Security Constraints . . . . . . . . . . . . . . . . . . . . 6 4.1. Device-Unique Key Requirement . . . . . . . . . . . . . . 6 4.2. No Fleet-Wide PSK . . . . . . . . . . . . . . . . . . . . 6 4.3. Device Identity Binding . . . . . . . . . . . . . . . . . 6 4.4. Key Storage . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Backend Trust Model . . . . . . . . . . . . . . . . . 7 4.5. Separation of Long-Term Device Key and DTLS PSK . . . . . 7 5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 8 5.2. EST Functions . . . . . . . . . . . . . . . . . . . . . . 8 Mittal & Hett Expires 12 April 2027 [Page 1] Internet-Draft EST-coaps-no-cert October 2026 5.3. Enrollment Flow . . . . . . . . . . . . . . . . . . . . . 9 6. DTLS Profile and Cipher Suite Recommendations . . . . . . . . 10 6.1. DTLS Version . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Recommended DTLS 1.3 Cipher Suite . . . . . . . . . . . . 10 6.3. Recommended DTLS 1.2 Cipher Suite . . . . . . . . . . . . 11 7. Authorization Requirements . . . . . . . . . . . . . . . . . 11 8. Proof-of-Possession . . . . . . . . . . . . . . . . . . . . . 12 9. Deployment Limitations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10.1. Unique Symmetric Keys Are Mandatory . . . . . . . . . . 13 10.2. PSK Entropy . . . . . . . . . . . . . . . . . . . . . . 13 10.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . 13 10.4. Replay and DoS Protection . . . . . . . . . . . . . . . 14 10.5. No 0-RTT Enrollment . . . . . . . . . . . . . . . . . . 14 10.6. Backend Key Retrieval . . . . . . . . . . . . . . . . . 14 10.7. Transition to Certificate-Based Authentication . . . . . 14 10.8. Device Credential Revocation . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 4 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Mittal & Hett Expires 12 April 2027 [Page 2] Internet-Draft EST-coaps-no-cert October 2026 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. 1. Introduction Enrollment over Secure Transport (EST), defined in [RFC7030], provides certificate enrollment over a secure transport and places the EST server logically between a Certification Authority and the client, performing functions commonly associated with a Registration Authority. [RFC9148] defines EST-coaps, which transports EST payloads over secure CoAP using DTLS for constrained IoT environments. [RFC9148] specifies certificate-based client authentication for EST- coaps, where EST-coaps client authentication is performed using a client certificate during the DTLS handshake. Devices that are already registered and operational may not possess a certificate suitable for EST-coaps client authentication. Such devices are therefore unable to use the certificate-based authentication model described in [RFC9148] for initial enrollment. This profile assumes that an external trust relationship between the device and the deployment ecosystem already exists before enrollment and that the device has been registered in an authoritative backend system. This document defines a constrained profile in which such devices authenticate to the EST-coaps server by using a DTLS PSK authentication. The PSK is either the device-unique symmetric key itself or a derived key generated from that device-unique symmetric key using a cryptographically approved key derivation function. The EST-coaps server or registrar obtains the corresponding keying material from an authoritative device registry, or key management system using the PSK identity presented by the device. This document does not modify EST enrollment semantics, certificate issuance procedures, proof-of-possession requirements, or certification authority policy. It defines an alternative EST-coaps authentication profile for devices that do not possess a certificate suitable for DTLS client authentication. This profile is intended to complement, rather than replace, the certificate-based authentication model defined in RFC 9148. Implementations that support certificate-based EST-coaps authentication remain fully compliant without support for this profile. Mittal & Hett Expires 12 April 2027 [Page 3] Internet-Draft EST-coaps-no-cert October 2026 This document only defines an alternative client authentication mechanism for the initial EST-coaps enrollment transaction. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. The terminology from [RFC7030] and [RFC9148] applies. This document additionally defines the following terms: +===============+==================================================+ | Term | Definition | +===============+==================================================+ | Field Device | A device that has already been deployed, | | | registered, and is operational in a production | | | network. | +---------------+--------------------------------------------------+ | No Initial | A fielded device that does not possess an | | Certificate | IDevID, manufacturer certificate, birth | | Device | certificate, or other certificate usable for the | | | initial EST-coaps DTLS client authentication. | +---------------+--------------------------------------------------+ | Device-Unique | A symmetric secret provisioned uniquely per | | Symmetric Key | device and known to an authoritative backend | | | system. | +---------------+--------------------------------------------------+ | PSK Identity | An identifier sent by the device during the DTLS | | | PSK handshake that allows the server to locate | | | the corresponding device-unique key or derived | | | PSK. | +---------------+--------------------------------------------------+ | Derived | A PSK derived from the device-unique symmetric | | Enrollment | key using a key derivation function and | | PSK | protocol-specific context. | +---------------+--------------------------------------------------+ | Authoritative | A backend system, or key management service that | | Device | binds each device identity to its unique | | Registry | symmetric key and authorization state. | +---------------+--------------------------------------------------+ Table 1: Definitions Mittal & Hett Expires 12 April 2027 [Page 4] Internet-Draft EST-coaps-no-cert October 2026 3. Applicability Statement This profile applies only when all of the following conditions are true: 1. The device is already registered in an authoritative backend system. 2. The device is already operational or has previously been authenticated by the deployment ecosystem. 3. The device does not have an initial certificate suitable for DTLS client authentication. 4. The device possesses a symmetric key that is unique to that device. 5. The backend can securely retrieve or derive the same PSK material based on the received PSK identity. 6. The goal is to obtain an operational certificate using EST or EST- coaps. This profile is *not* intended for devices that share a common fleet- wide symmetric key, rather this profile is intended for devices that have already established trust relationships with the deployment ecosystem through prior registration or deployment-specific provisioning procedures. 3.1. Trust Assumptions This profile assumes that each device has been provisioned with a symmetric key that is unique to that device and that the corresponding keying material is available to an authoritative backend system. The mechanisms used to generate, provision, distribute, or protect the device-unique symmetric key are outside the scope of this document. This profile further assumes that the backend system maintains an authoritative binding between the device identity, device status, and associated symmetric key material. The security of this profile depends on the integrity and confidentiality of that binding. Mittal & Hett Expires 12 April 2027 [Page 5] Internet-Draft EST-coaps-no-cert October 2026 4. Security Constraints 4.1. Device-Unique Key Requirement * Each device MUST be provisioned with a symmetric key that is cryptographically unique to that device. * A symmetric key MUST NOT be shared across multiple devices, product batches, manufacturing lots, utility deployments, or customer environments. * A device-unique key MUST have sufficient entropy to resist offline guessing attacks. TLS 1.3 explicitly warns that low-entropy PSKs or password-derived PSKs are vulnerable to brute-force or dictionary attacks based on observable PSK binders. * If a derived enrollment PSK is used, it MUST be derived using a cryptographically approved KDF that includes protocol-specific context, device identity, intended use, and deployment-specific context to prevent cross-protocol and cross-environment key reuse. Implementations SHOULD use HKDF, as defined by [RFC5869], or an equivalent NIST-approved key derivation mechanism. 4.2. No Fleet-Wide PSK A fleet-wide PSK MUST NOT be used. Compromise of a fleet-wide PSK would allow impersonation of all devices sharing that key and would prevent reliable attribution of enrollment requests to individual devices. 4.3. Device Identity Binding The PSK identity MUST uniquely identify the device or uniquely identify a backend record that maps to one device. The EST-coaps server or registrar MUST verify that: * the PSK identity maps to exactly one registered device. * the device is authorized for certificate enrollment. * the device has not been revoked, retired, replaced, or marked compromised. Mittal & Hett Expires 12 April 2027 [Page 6] Internet-Draft EST-coaps-no-cert October 2026 The syntax and structure of the PSK identity are deployment specific and are outside the scope of this specification. This profile does not define a mandatory PSK identity format. Profiles or deployments adopting this specification MAY define a mandatory PSK identity format to ensure interoperability among participating implementations. 4.4. Key Storage Device-unique symmetric keys MUST be stored in a protected device storage location appropriate to the device security profile. Backend copies of device-unique keys SHOULD be protected using an HSM, KMS, or equivalent key protection service. Access to device keys MUST be audited and limited to services that require the key for enrollment authentication. 4.4.1. Backend Trust Model The security of this profile depends upon the integrity, availability, and confidentiality of the authoritative device registry or key management system. The authoritative backend system MUST maintain a binding between device identity, enrollment status, lifecycle status and key material. Communication between the EST- coaps server or registrar and the authoritative backend system MUST be mutually authenticated and integrity protected. Access to device key material MUST be restricted to authorized services performing enrollment authentication functions. Deployments SHOULD ensure that device key retrieval, key usage, authorization decisions, enrollment approvals, and enrollment rejections are auditable. Unauthorized modification of backend device registrations can compromise enrollment authorization decisions. Deployments SHOULD therefore implement access controls, auditing, and change-management procedures appropriate for the operational environment. 4.5. Separation of Long-Term Device Key and DTLS PSK The long-term device-unique key SHOULD NOT be used directly as the DTLS PSK. Implementations SHOULD derive a dedicated enrollment PSK from the device-unique key using a cryptographically approved key derivation function. Direct use of the long-term device-unique key SHOULD only be used when device constraints or deployment limitations prevent derivation of a dedicated enrollment credential. DTLS PSK SHOULD be derived from the long-term device key using context such as: Mittal & Hett Expires 12 April 2027 [Page 7] Internet-Draft EST-coaps-no-cert October 2026 Derived-Enrollment-PSK = KDF(DeviceUniqueKey, label = "EST-coaps initial enrollment PSK", context = DeviceIdentity || DeploymentId || ESTServerId || ProtocolVersion) This separation reduces the risk that compromise or exposure of an enrollment PSK impacts other protocols or device functions. 5. Protocol Design 5.1. Protocol Layers This profile uses the same layering model as EST-coaps, except that DTLS client authentication is performed using PSK authentication rather than a client certificate. +------------------------------------------------+ | EST request/response messages | +------------------------------------------------+ | CoAP for message transfer and signaling | +------------------------------------------------+ | DTLS with device-unique PSK authentication | +------------------------------------------------+ | UDP | +------------------------------------------------+ Figure 5: EST-coaps PSK Protocol Layers [RFC9148] defines EST-coaps as EST payloads over CoAP protected by DTLS, and it uses CoAP Block-Wise Transfer for large EST payloads to avoid IP fragmentation. 5.2. EST Functions The following [RFC9148] EST-coaps functions remain applicable: Mittal & Hett Expires 12 April 2027 [Page 8] Internet-Draft EST-coaps-no-cert October 2026 +================+===========+==================================+ | EST Function | EST-coaps | This Profile | | | Short URI | | +================+===========+==================================+ | CA certificate | /crts | MUST support | | retrieval | | | +----------------+-----------+----------------------------------+ | Simple | /sen | MUST support | | enrollment | | | +----------------+-----------+----------------------------------+ | Simple re- | /sren | SHOULD support after operational | | enrollment | | certificate issuance | +----------------+-----------+----------------------------------+ | CSR attributes | /att | SHOULD support | +----------------+-----------+----------------------------------+ | Server-side | /skg or | NOT RECOMMENDED for this profile | | key generation | /skc | | +----------------+-----------+----------------------------------+ Table 2: EST-coaps Functions [RFC9148] maps EST operations such as /cacerts, /simpleenroll, /simplereenroll, and /csrattrs to shorter EST-coaps URI paths such as /crts, /sen, /sren, and /att. 5.3. Enrollment Flow A typical flow is: 1. The device initiates a DTLS connection to the EST-coaps registrar or server. 2. The device sends its PSK identity in the DTLS handshake. The PSK identity serves only as a lookup identifier and MUST NOT be treated as proof of device identity in the absence of successful PSK authentication. 3. The server uses the PSK identity to query the authoritative device registry. 4. The registry returns the device-specific PSK or sufficient material to derive it. 5. The DTLS handshake completes PSK authentication. 6. The device sends an EST /sen request containing a CSR. Mittal & Hett Expires 12 April 2027 [Page 9] Internet-Draft EST-coaps-no-cert October 2026 7. The EST-coaps server or registrar MUST verify that the authenticated PSK identity is authorized to obtain the certificate identifiers requested within the CSR Subject and Subject Alternative Name extensions. EST server MUST reject enrollment requests containing Subject or Subject Alternative Name values that are not associated with the authenticated device. 8. The CA issues the operational certificate. 9. After successful certificate enrollment, implementations SHOULD transition from PSK-based authentication to certificate-based authentication for subsequent EST operations, including re- enrollment. The PSK authentication mechanism defined in this profile is intended primarily for initial enrollment of devices that do not possess a suitable certificate for EST-coaps authentication. 6. DTLS Profile and Cipher Suite Recommendations 6.1. DTLS Version Implementations SHOULD support DTLS 1.3 as specified in [RFC9147]. DTLS 1.3 is based on TLS 1.3 and provides equivalent security properties except for order protection and non-replayability differences inherent to datagram transport. Implementations that require interoperability with existing constrained devices MAY support DTLS 1.2 as specified in [RFC6347]. [RFC9147] obsoletes [RFC6347], so DTLS 1.3 should be the preferred version for new implementations. 6.2. Recommended DTLS 1.3 Cipher Suite For DTLS 1.3, the following cipher suite is RECOMMENDED: TLS_AES_128_GCM_SHA256 or TLS_AES_256_GCM_SHA384 If the system uses PSK, implementations SHOULD use PSK with ephemeral Diffie-Hellman key establishment, also referred to as psk_dhe_ke, rather than PSK-only mode. TLS 1.3 allows PSKs to be used either alone or with (EC)DHE, and use with (EC)DHE provides forward secrecy while PSK-only does not. Recommended DTLS 1.3 profile: Mittal & Hett Expires 12 April 2027 [Page 10] Internet-Draft EST-coaps-no-cert October 2026 DTLS 1.3 Key Exchange Mode: psk_dhe_ke Cipher Suite: TLS_AES_128_GCM_SHA256 Alternative: TLS_AES_256_GCM_SHA384 Group: X25519 or secp256r1 0-RTT: MUST NOT be used for enrollment requests 6.3. Recommended DTLS 1.2 Cipher Suite For DTLS 1.2, the following cipher suites are RECOMMENDED: TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 or TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 As defined by [RFC5487], ECDHE-PSK cipher suites are RECOMMENDED to provide ephemeral key establishment, AEAD protection, and security characteristics appropriate for constrained environments. Recommended DTLS 1.2 profile: DTLS 1.2 Cipher Suite: TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 Alternative: TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 Group: secp256r1; X25519 where supported Compression: MUST NOT be used Renegotiation: MUST NOT be used for enrollment 7. Authorization Requirements Successful PSK authentication proves possession of the device’s symmetric key, but it does not by itself prove that the device should receive a certificate. Therefore, the EST-coaps server MUST perform authorization checks before forwarding or approving the CSR. If any authorization check defined in this section fails, the EST-coaps server or registrar MUST reject the enrollment request and MUST NOT forward the CSR to the Certification Authority. Authorization checks described in this section are applied during the enrollment flow defined in Section 5.3. The authorization decision MUST include: Mittal & Hett Expires 12 April 2027 [Page 11] Internet-Draft EST-coaps-no-cert October 2026 +=====================+==========================================+ | Check | Requirement | +=====================+==========================================+ | Device registration | PSK identity maps to a known registered | | | device | +---------------------+------------------------------------------+ | Key uniqueness | Device key is unique and not fleet- | | | shared | +---------------------+------------------------------------------+ | Device state | Device is active and not revoked, | | | decommissioned, replaced, or compromised | +---------------------+------------------------------------------+ | CSR identity | CSR subject and SAN values match the | | | registered device identity | +---------------------+------------------------------------------+ | Certificate profile | Requested certificate profile is allowed | | | for that device class | +---------------------+------------------------------------------+ | Rate limit | Enrollment attempts are rate limited per | | | device identity and source | +---------------------+------------------------------------------+ | Audit | Successful and failed enrollment | | | attempts are logged | +---------------------+------------------------------------------+ Table 3: Authorization Requirements [RFC7030] states that the EST server is responsible for authenticating and authorizing the client before acting on the request, and that certificate issuance remains controlled by local CA policy. 8. Proof-of-Possession The device MUST generate the key pair for the requested operational certificate unless server-side key generation is explicitly required by deployment policy. The CSR MUST include proof-of-possession by signing the CSR with the private key corresponding to the public key being certified. [RFC7030] describes proof-of-possession and linking identity to proof-of-possession using TLS channel binding information. For DTLS 1.2, implementations SHOULD bind the CSR to the authenticated DTLS session using the applicable channel-binding approach. Mittal & Hett Expires 12 April 2027 [Page 12] Internet-Draft EST-coaps-no-cert October 2026 For DTLS 1.3, implementations SHOULD use exporter-based channel binding where supported, since [RFC9148] notes that TLS 1.3 lacks the same tls-unique channel binding used in earlier TLS versions and discusses use of exporter-derived binding for TLS 1.3 contexts. 9. Deployment Limitations This profile has the following limitations: 1. Initial trust depends on the secrecy and uniqueness of the symmetric device key. 2. Compromise of a device-unique key permits impersonation of that device until the key or device record is revoked. 3. The PSK identity may expose information about the device if it contains a serial number, asset identifier, meter identifier, IMEI, MAC address, or another deployment-specific identifier. 4. Backend key lookup introduces dependency on the availability and security of the authoritative device registry. 5. This profile does not bootstrap unknown devices. 6. This profile does not remove the need for normal PKI validation after the operational certificate is issued. 10. Security Considerations 10.1. Unique Symmetric Keys Are Mandatory The strongest security constraint in this profile is that every device MUST have a unique symmetric key. A common or fleet-shared key would allow one compromised device to impersonate other devices and would defeat per-device authorization. 10.2. PSK Entropy PSKs and device-unique symmetric keys MUST be generated with sufficient randomness. TLS 1.3 warns that low-entropy out-of-band PSKs are vulnerable to brute-force attacks and that PSK authentication is not a strong password-authenticated key exchange. 10.3. Forward Secrecy DTLS 1.3 PSK-only mode SHOULD NOT be used for enrollment because it does not provide forward secrecy. DTLS 1.3 PSK with ECDHE SHOULD be used where supported. Mittal & Hett Expires 12 April 2027 [Page 13] Internet-Draft EST-coaps-no-cert October 2026 10.4. Replay and DoS Protection DTLS includes mechanisms for datagram environments, including retransmission handling, handshake fragmentation, and replay detection. DTLS 1.2 uses sequence numbers and optional replay detection, and DTLS 1.3 similarly addresses packet loss, reordering, fragmentation, and replay detection. Servers SHOULD enable DTLS anti-replay protections and MUST rate limit failed PSK handshakes and failed enrollment attempts. 10.5. No 0-RTT Enrollment Enrollment requests MUST NOT be sent using DTLS 1.3 0-RTT data. TLS 1.3 0-RTT data has weaker security properties and can be replayed across connections. 10.6. Backend Key Retrieval The EST-coaps registrar or server MUST authenticate to the backend system before retrieving device key material. Backend responses MUST be integrity protected and confidential. Key retrieval events MUST be auditable. 10.7. Transition to Certificate-Based Authentication After successful certificate issuance, the device SHOULD use the issued operational certificate for future EST re-enrollment and other certificate-authenticated network access. This aligns with the existing EST and EST-coaps model where certificates are used for later authentication. Continued use of PSK authentication after issuance of an operational certificate may unnecessarily extend reliance on shared-secret authentication mechanisms. Where practical, deployments SHOULD transition to certificate-based authentication following successful enrollment. 10.8. Device Credential Revocation Deployments MUST provide a mechanism to disable, revoke, or otherwise invalidate device credentials when a device is determined to be compromised, replaced, retired, or no longer authorized. The EST-coaps server or registrar MUST reject enrollment requests originating from devices whose associated credentials have been revoked or disabled within the authoritative device registry. Mittal & Hett Expires 12 April 2027 [Page 14] Internet-Draft EST-coaps-no-cert October 2026 Revocation events SHOULD be auditable and propagated in a timely manner to all systems responsible for enrollment authorization decisions. 11. IANA Considerations This draft does not initially require new IANA registrations if it reuses existing EST-coaps resources, CoAP content formats, and DTLS cipher suites. Future revisions of this specification may define a new discovery resource type or EST-coaps profile indicator. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5487] Eronen, P. and H. Tschofenig, "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", March 2009, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Mittal & Hett Expires 12 April 2027 [Page 15] Internet-Draft EST-coaps-no-cert October 2026 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, April 2022, . 12.2. Informative References [NIST.SP.800-108] Technology, N. I. O. S. A., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, 2009, . Authors' Addresses Narinder Mittal Landis+Gyr Email: narinder.mittal@landisgyr.com Chris Hett Landis+Gyr Email: chris.hett@landisgyr.com Mittal & Hett Expires 12 April 2027 [Page 16]