Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate Revocation #56

Merged
merged 5 commits into from
Sep 23, 2024
+12 −12
Merged

Certificate Revocation #56

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
81fcd26
Certificate Revocation
hannestschofenig Sep 16, 2024
ed7ba3a
Update draft-ietf-uta-tls13-iot-profile.md
hannestschofenig Sep 16, 2024
776d116
edits from TF
mcr Sep 18, 2024
a175e43
Update draft-ietf-uta-tls13-iot-profile.md
hannestschofenig Sep 23, 2024
3dc2dfd
Update draft-ietf-uta-tls13-iot-profile.md
hannestschofenig Sep 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions draft-ietf-uta-tls13-iot-profile.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -448,22 +448,23 @@ 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 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 and these protocols, some of which are standardized,
allow updates of certificates on demand. This enables a
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
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 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.
and CRLs, less relevant. Whenever certificates are updated the TLS stack
needs to be informed since the communication 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 is triggered when the application requires it. TLS 1.3 provides
client-to-server post-handshake authentication only. Mutual
authentication via post-handshake messages is available by the use of 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
Expand All @@ -476,7 +477,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.
Expand Down
Loading