Skip to content

Commit

Permalink
move rfc9525 to EE section
Browse files Browse the repository at this point in the history
  • Loading branch information
mcr committed Sep 2, 2024
1 parent 258dee8 commit 2bc415f
Showing 1 changed file with 8 additions and 5 deletions.
13 changes: 8 additions & 5 deletions draft-ietf-uta-tls13-iot-profile.md
Original file line number Diff line number Diff line change
Expand Up @@ -394,9 +394,9 @@ to {{!RFC5280}}.
In IoT deployment scenarios it is often expected that the IDevIDs have
no maximum validity period. For this purpose the use of a special value
for the notAfter date field, the GeneralizedTime value of 99991231235959Z,
is utilized. If this is done, then CA certificates and certificates of
subordinate CAs cannot have a maximum validity period either. Hence,
it requires careful consideration whether it is appropriate to issue
is utilized.
If this is done, then the CA certificates and the certificates of subordinate CAs cannot have a maximum validity period either.
Hence, it requires careful consideration whether it is appropriate to issue
IDevID certificates with no maximum validity period.

LDevID certificates are, however, issued by the operator or owner,
Expand Down Expand Up @@ -489,10 +489,11 @@ field." RFC 5280 adds "If the subject is a CA then the subject field MUST be
populated with a non-empty distinguished name matching the contents of the
issuer field in all certificates issued by the subject CA."

However, as {{!RFC9525, Section 2}} mandates that the subjectDN not be be used to identify a service, for IoT purposes, an empty SubjectDN avoids all confusion for End Entity certificates.

Root CA certificates and Subordinate CA certificates MUST have a non-empty SubjectDN, as the value MUST match the DN of the Issuer.

The Subject field MUST be set and MUST contain the commonName, the organizationName,
and the countryName attribute and MAY contain an organizationalUnitName attribute.

### Authority Key Identifier

Section 4.2.1.1 of {{!RFC5280}} defines the Authority Key Identifier as follows:
Expand Down Expand Up @@ -618,6 +619,8 @@ This section outlines the requirements for end entity certificates.

### Subject

{{!RFC9525, Section 2}} mandates that the subjectDN not be be used to identify a service, for IoT purposes, an empty SubjectDN avoids all confusion for End Entity certificates.

The requirement in Section 4.4.2 of {{!RFC7925}} to only use EUI-64 for end
entity certificates as a Subject name is lifted.

Expand Down

0 comments on commit 2bc415f

Please sign in to comment.