From 81fcd26c9280c6d0ce9ebeb5b575049c4bc17fc7 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 16 Sep 2024 15:59:55 +0200 Subject: [PATCH] Certificate Revocation --- draft-ietf-uta-tls13-iot-profile.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 5214e56..9f04f7f 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -448,12 +448,14 @@ Since the publication of RFC 7925 the need for firmware update mechanisms has been reinforced and the work on standardizing a secure and interoperable firmware update mechanism has made substantial progress, see {{?RFC9019}}. RFC 7925 recommends to use a software / firmware update -mechanism to provision devices with new trust anchors. +mechanism to provision devices with new trust anchors. This approach does, +however, only address the distribution of trust anchors and not end-entity +certificates or certificates of subordinate CAs. The use of device management protocols for IoT devices, which often include an onboarding or bootstrapping mechanism, has also seen considerable uptake in deployed devices and these protocols, some of which are standardized, -allow updates of certificates on demand. This enables a +allow distribution and updates of certificates on demand. This enables a deployment model where IoT device utilize end-entity certificates with shorter lifetime making certificate revocation protocols, like OCSP and CRLs, less relevant. Whenever certificates @@ -462,8 +464,9 @@ endpoints need to be aware of the new certificates. This is particularly important when long-lived TLS connections are used. In such a case, the a post-handshake authentication exchange needs to be triggered. TLS 1.3 provides client-to-server post-handshake authentication only. Mutual -authentication via post-handshake messages is available via {{?RFC9261}} -but requires the application layer protocol to carry the payloads. +authentication via post-handshake messages is available via the "Exported +Authenticator" {{?RFC9261}} but requires the application layer protocol +to carry the payloads. Hence, instead of performing certificate revocation checks on the IoT device itself this specification recommends to delegate this task to the IoT device @@ -476,7 +479,6 @@ extension indicates how to access information like the online certificate status service (OCSP). Both extensions SHOULD NOT be set. If set, they MUST NOT be marked critical. - ## Root CA Certificate This section outlines the requirements for root CA certificates.