diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md
index 66d7424..e20694c 100644
--- a/draft-ietf-uta-tls13-iot-profile.md
+++ b/draft-ietf-uta-tls13-iot-profile.md
@@ -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,
@@ -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:
@@ -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.