use subjectName for all uses

thomas-fossati · Sep 2, 2024 · 5f34751 · 5f34751
1 parent 7461b8d
commit 5f34751
Showing 1 changed file with 8 additions and 9 deletions.
diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md
@@ -481,18 +481,17 @@ MUST NOT be marked critical.
 
 This section outlines the requirements for root CA certificates.
 
-### Subject
+## subjectName
 
-{{!RFC5280}} defines the Subject field as follows: "The subject field identifies
+{{!RFC5280}} defines the subjectName field as follows: "The subject field identifies
 the entity associated with the public key stored in the subject public key
 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."
 
 Root CA certificates MUST have a non-empty SubjectDN.
 
-The Subject field MUST be set and MUST contain the commonName, the organizationName,
-and the countryName attribute and MAY contain an organizationalUnitName attribute.
+The subjectName MUST contain the commonName, the  organizationName, and the countryName attribute and MAY contain an organizationalUnitName attribute.
 
 ### Authority Key Identifier
 
@@ -567,9 +566,9 @@ be set to true and the pathLenConstraint MUST be omitted.
 
 This section outlines the requirements for subordinate CA certificates.
 
-### Subject
+### subjectName
 
-The Subject field MUST be set and MUST contain the commonName, the organizationName,
+The subjectName field MUST be set and MUST contain the commonName, the organizationName,
 and the countryName attribute and MAY contain an organizationalUnitName attribute.
 
 
@@ -617,12 +616,12 @@ status service (OCSP).
 
 This section outlines the requirements for end entity certificates.
 
-### Subject
+### subjectName
 
-{{!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.
+{{!RFC9525, Section 2}} mandates that the subjectName not be be used to identify a service, for IoT purposes, an empty subjectName 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.
+entity certificates as a subjectName is lifted.
 
 Two fields are typically used to encode a device identifer, namely the
 Subject and the subjectAltName fields. Protocol specifications tend to offer