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

chore: use "end entity certificate" consistently, per RFC5280 #68

Merged
merged 1 commit into from
Dec 16, 2024
Merged

chore: use "end entity certificate" consistently, per RFC5280 #68

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 4 additions & 4 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 @@ -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.

Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down
Loading