From 7d32548cc8f0740d06f0180603e31f5cae2125a8 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Mon, 16 Dec 2024 17:41:07 +0100 Subject: [PATCH] chore: use "end entity certificate" consistently, per RFC5280 Fix #67 Signed-off-by: Thomas Fossati --- draft-ietf-uta-tls13-iot-profile.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 561228a..cf0999d 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -445,7 +445,7 @@ following algorithms: - id-ecPublicKey with secp521r1. There is no requirement to use CA certificates and certificates of -subordinate CAs to use the same algorithm as the end-entity certificate. +subordinate CAs to use the same algorithm as the end entity certificate. Certificates with longer lifetime may well use a cryptographic stronger algorithm. @@ -459,13 +459,13 @@ 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. This approach only addresses the distribution of trust anchors and not end-entity certificates or certificates of subordinate CAs. +mechanism to provision devices with new trust anchors. This approach only addresses 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. These protocols, some of which are standardized, allow for the distribution and updating of certificates on demand. This enables a -deployment model where IoT device utilize end-entity certificates with +deployment model where IoT device utilize end entity certificates with shorter lifetime making certificate revocation protocols, like OCSP and CRLs, less relevant. Whenever certificates are updated the TLS stack needs to be informed since the communication endpoints need to be aware @@ -659,7 +659,7 @@ and MUST contain the subjectKeyIdentifier of the CA that issued this certificate ### Subject Key Identifier -The Subject Key Identifier MUST NOT be included in end-entity certificates, as it can be calculated from the public key, so it just takes up space. +The Subject Key Identifier MUST NOT be included in end entity certificates, as it can be calculated from the public key, so it just takes up space. End entity certificates are not used in path construction, so there is no ambiguity regarding which certificate chain to use, as there can be with subordinate CAs. ### Key Usage