Skip to content

Commit

Permalink
Merge pull request #51 from thomas-fossati/hannestschofenig-patch-1
Browse files Browse the repository at this point in the history
Certificate Revocation Update
  • Loading branch information
hannestschofenig authored Feb 23, 2024
2 parents 60235fb + 3d53c23 commit d7e5ab7
Showing 1 changed file with 10 additions and 7 deletions.
17 changes: 10 additions & 7 deletions draft-ietf-uta-tls13-iot-profile.md
Original file line number Diff line number Diff line change
Expand Up @@ -440,7 +440,9 @@ algorithm.

### Certificate Revocation Checks

The considerations in Section 4.4.3 of {{!RFC7925}} hold.
The guidance in {{Section 4.4.3 of !RFC7925}} still holds: for certificate
revocation, neither the Online Certificate Status Protocol (OCSP) nor
Certificate Revocation Lists (CRLs) are used by constrained IoT devices.

Since the publication of RFC 7925 the need for firmware update mechanisms
has been reinforced and the work on standardizing a secure and
Expand All @@ -451,14 +453,15 @@ mechanism to provision devices with new trust anchors.
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 a regular basis. This enables a
allow 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. If TLS connections are long-lived, a trigger
by the application layer is necessary to perform post-handshake authentication
to exchange the newly provisioned certificates. This will allow both peers
to learn about any certificate changes. TLS 1.3 provides basic
post-handshake client-to-server authentication only. Mutual
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.

Expand Down

0 comments on commit d7e5ab7

Please sign in to comment.