Please move it forward. Thanks for addressing my comments. Yours, Daniel
Daniel Migault Ericsson On Thu, Feb 5, 2026, 3:34 a.m. Valery Smyslov <[email protected]> wrote: > Hi Hannes, > > > > thank you for updating the document. I believe that the document can be > sent to the IESG. > > If anyone disagrees (Daniel?), please chime in within two weeks. > > > > Regards, > > Valery. > > > > Hi Daniel, > > Thank you for the additional review. I went through your feedback, > updated the draft and submitted version -18. > > Here is the new version: > https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-18.txt > > Here is the diff: > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-uta-tls13-iot-profile-17&url2=draft-ietf-uta-tls13-iot-profile-18&difftype=--html > > Here is a short summary of changed: > > - Clarified that TLS 1.3 post-handshake authentication is client only, and > adjusted wording accordingly. > - Replaced the term "dummy message" with neutral wording. > - Explicitly clarified "non-PSK-based" as certificate-based authentication. > - Fixed wording/typos and tightened terminology in the credential types > section, including clarifying external-PSK vs resumption-PSK and noting > that the mandatory extension list applies to external-PSK-only usage. > - Added a short statement at the start of the credential section to > clarify the authentication modes in scope (certificate/RPK vs external PSK). > - Added guidance for PSK + (EC)DHE to preserve forward secrecy, and > tightened 0-RTT language to apply to any application protocol unless a > profile exists (not just CoAP). > - Adjusted the compression section to clarify that TLS 1.3 does not define > compression, while still noting handshake-size reduction mechanisms. > - Reworked the revocation checks section to make the AIA/CRLDP guidance > clearer), and clarified that continuous validation is the responsibility of > the application rather than a mechanism provided by the TLS stack. > - Clarified that certificate updates do not affect existing TLS sessions; > re-auth or re-establishment is (again) an application decision. > - In the certificate profile, clarified IDevID purpose, wording around > IDevID profiles, and added rationale for not claiming full IEEE 802.1AR > conformance. > - Added a note that the "All Certificates" section applies to IoT device > PKI, not public WebPKI. > - Tightened requirements for signature algorithms, subject public key > algorithms, and key usage/identifier extensions for CA certificates, > including guidance aligned with constrained validation capabilities. > > Thanks again for the very detailed review. > > I hope that this draft update completes the work on this document from the > working group point of view. > > Ciao > Hannes > > Am 07.11.2025 um 18:29 schrieb Daniel Migault: > > Hi, > > > > I have several remarks regarding the current draft. These are primarily > minor issues, so you may choose to address them or disregard them and > proceed with the document. > > One observation that I believe holds greater significance is that, in my > view, the ongoing validation of the certificate throughout an extended TLS > session is not a function of TLS itself, but rather a requirement of the > application. I think the text should be clearer on this point. > > Additionally, I am curious about the necessity of presenting the complete > chain in a TLS exchange. Generally, I am questioning whether it would be > feasible to provide only the End Entity (EE) certificate and utilize > Authority Information Access (AIA) to obtain the complete chain, for > instance. > > > > Other comments: > > > > > > > TLS/DTLS 1.3 Profiles for the Internet of Things > draft-ietf-uta-tls13-iot-profile-17 > > Abstract > > RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for > Internet of Things (IoT) devices with resource constraints. This > > mglt: I am not sure we need to mention TLS 1.2 > > document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles > for IoT devices. Additionally, it updates RFC 7925 with respect to > the X.509 certificate profile and ciphersuite requirements. > > > 1. Introduction > > ... > > TLS 1.3 has been re-designed and several previously defined > extensions are not applicable to the new version of TLS/DTLS anymore. > The following features changed with the transition from TLS 1.2 to > 1.3: > > * TLS 1.3 introduced the concept of post-handshake authentication > messages, which partially replaced the need for the re-negotiation > feature [RFC5746] available in earlier TLS versions. However, the > rekeying mechanism defined in Section 4.6.3 of [TLS13] does not > provide post-compromise security (see Appendix E.1.5 of [TLS13]). > Furthermore, post-handshake authentication defined in > Section 4.6.2 of [TLS13] only offers client-to-server > authentication. > > mglt: isn't it client authentication ? > > The "Exported Authenticator" specification, see > [RFC9261], added support for mutual post-handshake authentication, > but this requires the Certificate, CertificateVerify and the > Finished messages to be conveyed by the application layer > protocol, as it is exercised for HTTP/2 and HTTP/3 in > [I-D.ietf-httpbis-secondary-server-certs]. Therefore, the > application layer protocol must be enhanced whenever this feature > is required. > * Rekeying of the application traffic secret does not lead to an > update of the exporter secret (see Section 7.5 of [TLS13]) since > the derived export secret is based on the exporter_master_secret > and not on the application traffic secret. > * Flight #4, which was used by EAP-TLS 1.2 [RFC5216], does not exist > in TLS 1.3. As a consequence, EAP-TLS 1.3 [RFC9190] introduced a > dummy message. > > mglt: I think dummy is part of banned words. > > * [RFC4279] introduced PSK-based authentication to TLS, a feature > re-designed in TLS 1.3. The "PSK identity hint" defined in > [RFC4279], which is used by the server to help the client in > selecting which PSK identity to use, is, however, not available > anymore in TLS 1.3. > * Finally, ciphersuites were depreciated and the RSA-based key > transport is not supported in TLS 1.3. As a consequence, only a > Diffie-Hellman-based key exchange is available for non-PSK-based > authentication. (For PSK-based authentication the use of Diffie- > Hellman is optional.) > > mglt: I suspect non-PSK-based means certificate based. It is my belief the > latest is clearer. > > ... > > 2. Conventions and Terminology > > ... > > 3. Credential Types > > TLS/DTLS allow different credential types to be used. These include > X.509 certificates and raw public keys, pre-shared keys (PSKs), and > passwords. The extensions used in TLS/DTLS differ dependencing on > the credential types supported. > > mglt: dependencing > > TLS/DTLS 1.3 supports PSK-based authentication, wherein PSKs can be > established via session tickets from prior connections or via some > external, out-of-band mechanism. To distinguish the two modes, the > former is called resumption PSK and the latter external PSK. For > performance reasons the support for resumption PSKs is often found in > implementations that use X.509 certificates for authentication. > > mglt: what about the external PSK ? > > A "plain" PSK-based TLS/DTLS client or server, which only implements > support for external PSKs as its long-term credential, MUST implement > the following extensions: > > * Supported Versions, > * Cookie, > * Server Name Indication (SNI), > * Pre-Shared Key, > * PSK Key Exchange Modes, and > * Application-Layer Protocol Negotiation (ALPN). > > mglt: my reading of teh text was that the extensions MUST be supported for > the purpose of supporting clients and server supporting external PSK > authentication. I actually believe that these options are also carried when > ECDHE or session resumption is handled. I THINK we should explicitly > mention these options can be carried by other clients. > > For use of external pre-shared keys [RFC9258] makes the following > recommendation: > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 5] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > Applications SHOULD provision separate PSKs for (D)TLS 1.3 and > prior versions. > > mglt: itemizing for a single recommendation may not be necessary. We > shoudl probably stick to external PSK. > > Where possible, the importer interface defined in [RFC9258] MUST be > used for external PSKs. This ensures that external PSKs used in > (D)TLS 1.3 are bound to a specific key derivation function (KDF) and > hash function. > > The SNI extension is discussed in this document and the justification > for implementing and using the ALPN extension can be found in > [RFC9325]. > > mglt: the paragraph does not add uch details. I believe it should simply > say ALPN is discuses in section XXX. > > An implementation supporting authentication based on certificates and > raw public keys MUST support digital signatures with > ecdsa_secp256r1_sha256. A compliant implementation MUST support the > key exchange with secp256r1 (NIST P-256) and SHOULD support key > exchange with X25519. > > mglt: I am surprised to find client ECDHE after we described PSK > authentication. I think what is missing in the begining is the mention that > IoT considers certificate and external PSK authentication. This would > clearly state which modes are considered. For now PSK + ECDHE combined is > not considered. It will also prepare the reader to get both types of > recommendations. > > For TLS/DTLS clients and servers implementing raw public keys and/or > certificates the guidance for mandatory-to-implement extensions > described in Section 9.2 of [RFC8446] MUST be followed. > > mglt: is self signed cert considered as raw key ? > > Entities deploying IoT devices may select credential types based on > security characteristics, operational requirements, cost, and other > factors. Consequently, this specification does not prescribe a > single credential type but provides guidance on considerations > relevant to the use of particular types. > > 4. Error Handling > > ... > > 5. Session Resumption > > TLS 1.3 has built-in support for session resumption by utilizing PSK- > based credentials established in an earlier exchange. > > > mglt: The section looks very strange. I suspect the reason is that you > follow the TLS 1.2 structure. Please make it explicit. > > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 6] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 6. Compression > > ... > > With regards to the handshake itself, various strategies have been > applied to reduce the size of the exchanged payloads. TLS and DTLS > 1.3 use less overhead, depending on the type of key confirmations, > when compared to previous versions of the protocol. Additionally, > the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken > compression of the handshake a step further by utilizing out-of-band > knowledge between the communication parties to reduce the amount of > data to be transmitted at each individual handshake, among applying > other techniques. > > mglt: In it current form, it is suprising to have a section to mention TLS > 1.3 does not support the property. > > 7. Forward Secrecy > > RFC 8446 has removed Static RSA and Static Diffie-Hellman cipher > suites, therefore all public-key-based key exchange mechanisms > available in TLS 1.3 provide forward secrecy. > > Pre-shared keys (PSKs) can be used with (EC)DHE key exchange to > provide forward secrecy or can be used alone, at the cost of losing > forward secrecy for the application data. > > mglt: this section is a bit strange in the sense that there is no > recommendation on whether ECHDE shoudl be used with PSK. > > 8. Authentication and Integrity-only Cipher Suites > > For a few, very specific Industrial IoT use cases [RFC9150] defines > two cipher suites that provide data authenticity, but not data > confidentiality. Please review the security and privacy > considerations about their use detailed in Section 9 of [RFC9150]. > > mglt: I think this document should completely differ to 9150 beyond the > section 9 - especially as I am expecting a very few number of tls libraries > to support it - but I might be wrong. > > 9. Keep-Alive > > The discussion in Section 10 of [RFC7925] is applicable. > > 10. Timers and ACKs > > Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS > 1.3 ACKs sensibly decrease the risk of congestion collapse which was > the basis for the very conservative recommendations given in > Section 11 of [RFC7925]. > > In general, the recommendations in Section 7.3 of [DTLS13] regarding > ACKs apply. In particular, "(w)hen DTLS 1.3 is used in deployments > > mglt: Do you mean applies for TLS 1.3 AND DTLS 1.3. If so, I beleiev this > should be made explicit. > > with lossy networks, such as low-power, long-range radio networks as > > > ... > > Due to the vast range of network technologies used in IoT > deployments, from wired LAN to GSM-SMS, it's not possible to provide > a universal recommendation for an initial timeout. Therefore, it is > RECOMMENDED that DTLS 1.3 implementations allow developers to > explicitly set the initial timer value. Developers SHOULD set the > initial timeout to be twice the expected round-trip time (RTT), but > no less than 1000ms. For specific application/network combinations, > > mglt: it would be good to explain where that 1000 ms comes from. > > a sub-second initial timeout MAY be set. In cases where no RTT > estimates are available, a 1000ms initial timeout is suitable for the > general Internet. > > For RRC, the recommendations in Section 7.5 of > [I-D.ietf-tls-dtls-rrc] apply. Just like the handshake initial > timers, it is RECOMMENDED that DTLS 1.2 and 1.3 implementations offer > an option for their developers to explicitly set the RRC timer. > > 11. Random Number Generation > ... > > 12. Server Name Indication > > This specification mandates the implementation of the Server Name > Indication (SNI) extension. Where privacy requirements require it, > > mglt: I do nto see why SNI is mandated. I believe this is too strong. I > would prefer a SHOULD with the explanation to why this is recommended. I > suspect this is is to interact with services hosted in the cloud. > > the ECH (Encrypted Client Hello) extension [I-D.ietf-tls-esni] > prevents an on-path attacker to determine the domain name the client > is trying to connect to. > > ... > > 13. Maximum Fragment Length Negotiation > > The Maximum Fragment Length Negotiation (MFL) extension has been > superseded by the Record Size Limit (RSL) extension [RFC8449]. > Implementations in compliance with this specification MUST implement > the RSL extension and SHOULD use it to indicate their RAM > limitations. > > mglt: I think RAM limitation is only one example. What came immediately to > my mind is that the device MUST ensure large packets are discarded. > > 14. Crypto Agility > ... > > 15. Key Length Recommendations > > ... > > 16. 0-RTT Data > > Appendix E.5 of [TLS13] establishes that: > > Application protocols MUST NOT use 0-RTT data without a profile > that defines its use. That profile needs to identify which > messages or interactions are safe to use with 0-RTT and how to > handle the situation when the server rejects 0-RTT and falls back > to 1-RTT. > > At the time of writing, no such profile has been defined for CoAP > [CoAP]. Therefore, 0-RTT MUST NOT be used by CoAP applications. > > mglt: this sounds for other non-CoAP as a SHOULD NOT unless.... > > 17. Certificate Profile > > ... > > IDevIDs are primarily used with device onboarding or bootstrapping > protocols, such as the Bootstrapping Remote Secure Key Infrastructure > (BRSKI) protocol [RFC8995] or by LwM2M Bootstrap [LwM2M-T] [LwM2M-C]. > Hence, the use of IDevIDs is limited on purpose even though they have > a long lifetime, or do not expire at all. > > mglt: I think the purpose needs to be specified. In general any > certificate has a purpose. > > While some bootstrapping > protocols use TLS (and therefore make use of the IDevID as part of > client authentication) there are other bootstrapping protocols that > do not use TLS/DTLS for client authentication, such as FIDO Device > Onboarding (FDO) [FDO]. In many cases, a profile for the certificate > content is provided by those specifications. For these reasons, this > specification focuses on the description of LDevIDs. > > mglt: The last sentence is unclear to me. I think the "certificate > content" should be replaced by IDevIDs. > > This document uses the terminology and some of the rules for > populating certificate content defined in IEEE 802.1AR. However, > this specification does not claim conformance to IEEE 802.1AR. since > such a compliance statement goes beyond the use of the terminology > and the certificate content and would include the use of management > protocols, fulfillment of certain hardware security requirements, and > interfaces to access these hardware security modules. Placing these > requirements on network equipment like routers may be appropriate but > designers of constrained IoT devices have opted for different > protocols and hardware security choices. > > mglt: I think we need to explain why we do not refer simply to 802.1AR. It > seems we are defining a profile that look s like 802.1AR but still > different. The question becomes why should we add another standard as > opposed to using 802.1AR. > > 17.1. All Certificates > > mglt: we probably need to explain why we have "All Certificates". The > profile as I understand is limited to the certificate that represents the > IoT device. This means that if an IoT device contact a Web Server. The IoT > device will have the certificate in this document while the Web Server will > have the CABF. > > To avoid repetition, this section outlines requirements on X.509 > certificates applicable to all PKI entities. > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 10] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 17.1.1. Version > > Certificates MUST be of type X.509 v3. > > mglt: and v3 = 2 ;-). The text below is in my opinion not related to the > version section and could be moved to the intro of the certificate section > 17. > > Note that TLS 1.3 allows to > convey payloads other than X.509 certificates in the Certificate > message. The description in this section only focuses on X.509 v3 > certificates and leaves the description of other formats to other > sections or even other specifications. > > 17.1.2. Serial Number > > CAs MUST generate non-sequential serial numbers greater than or equal > to eight (8) octets from a cryptographically secure pseudo-random > number generator. [RFC5280] limits this field to a maximum of 20 > octets. The serial number MUST be unique for each certificate issued > by a given CA (i.e., the issuer name and the serial number uniquely > identify a certificate). > > This requirement is aligned with [RFC5280]. > > mglt: not CABF provides additional requirement on the randome generator. > > 17.1.3. Signature > > The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. > > Note: In contrast to IEEE 802.1AR this specification does not require > end entity certificates, subordinate CA certificates, and CA > certificates to use the same signature algorithm. Furthermore, this > specification does not utilize RSA for use with constrained IoT > devices and networks. > > mglt: using different signatures requires the IoT device to support all > these signature scheme. It makes sense for certificates verified by IoT > devices to have a single signature. > > 17.1.4. Issuer > > The issuer field MUST contain a non-empty distinguished name (DN) of > the entity that has signed and issued the certificate in accordance > with [RFC5280]. > > 17.1.5. Validity > > Vendors must determine the expected lifespan of their IoT devices. > This decision directly affects how long firmware and software updates > are provided for, as well as the level of maintenance that customers > can expect. It also affects the maximum validity period of > certificates. > > In most IoT deployments, IDevIDs are provisioned with an unlimited > lifetime as per [IEEE-802.1AR]. For this purpose, a special value > for the notAfter date field, the GeneralizedTime value of > 99991231235959Z, is utilized. This special value was introduced in > Section 4.1.2.5 of [RFC5280]. When this is done, then the CA > > ... > > mglt: The problem is that a device that is unable to determien which UTC > time it is can hardly ensure the notAfter especially as leap seconds can be > added or removed. The CABF text is quite confusing to me, but it seems the > reasonable way to do is to ignore leap seconds and define days as 8640 > oseconds. This seems to me close to TAI than UTC - with non atomic clock, a > UT1 or pre-50 conception of the second, while certificates expresses time > in UTC. I think what is more important is to say that systems do not have a > precision of the second. > > 17.1.6. Subject Public Key Info > > The subjectPublicKeyInfo field indicates the algorithm and any > associated parameters for the ECC public key. This profile uses the > id-ecPublicKey algorithm identifier for ECDSA signature keys, as > defined and specified in [RFC5480]. This specification assumes that > devices supported one of the following algorithms: > > * id-ecPublicKey with secp256r1, > * id-ecPublicKey with secp384r1, and > * 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. Certificates with longer lifetime may well use a > cryptographic stronger algorithm. > > mglt: we should probably recommend it when the certificate needs to be > validated by an IoT. > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 12] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 17.1.7. Certificate Revocation Checks > > The Certificate Revocation Lists (CRLs) distribution points extension > has been defined in RFC 5280 to identify how CRL information is > obtained. The authority information access extension indicates how > to access information like the online certificate status service > (OCSP). Both extensions SHOULD NOT be set. > > mglt: The sentence is confusing. It might be clearer to provide the > explicit recommended combination of extensions. AIK may contains caissuer > as well which is unrelated to CRL, so I do not clearly see why these > extensions are not recommened to be used together. The coexistence might > also depends on the lifetime of the certificates. > > If set, they MUST NOT be > marked critical. > > Instead of using CRLs or OCSP this document follows the guidance in > Section 4.4.3 of [RFC7925]: for certificate revocation, neither OCSP > nor CRL are used by constrained IoT devices. > > mglt: It is unclear if that recommendation is one step further than the > previous one or if the previous one was NEITHER extensions SHOULD be set. > > 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. An example of a standardized IoT device > management protocol is the Lightweight Machine-to-Machine (LwM2M) > [LwM2M-T] [LwM2M-C] protocol. Device management protocols enable a > deployment model where IoT devices 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 of the new certificates. > > mglt: this is not correct. TLS authenticates during the handshake, so new > certificates renewal does not affect the end point of the communications. > If the end points want to constantly validate the certificate, this is a > policy that is separate from TLS and in effect TLS does not permit this. > This has to be done via HTTP for example. > > This is particularly important > when long-lived TLS connections are used. In such a case, the post- > handshake authentication exchange is triggered when the application > requires it. TLS 1.3 provides client-to-server post-handshake > authentication only. Mutual authentication via post-handshake > messages is available by the use of the "Exported Authenticator" > [RFC9261] but requires the application layer protocol to carry the > payloads. > > mglt: Continuous certificate validation goes beyond TLS, and is outside > the scope of this draft in my opinion. It might be interesting information > but what needs to be added is what is the advantage over re-establishing ab > ECDHE TLS session. > > Hence, instead of performing certificate revocation checks on the IoT > device itself this it is RECOMMENDED to delegate this task to the IoT > device operator and to take the necessary action to allow IoT devices > to remain operational. > > mglt: we need to specify what certificate revocation checks are considered > here - continuous certificate validity versus crl/ocsp. I think the point > is more, that OCSP/CRL extension can be omitted only when the operator of a > control and managed system can ensure certificates present are up to date. > > > dm: It is my beleive that a specific OID policy shoudl be provide for the > profile. > > mglt: I just realized the section is generic to Root CA, Subordinate and > End ENtity certificates. Some comments might only be related to EE. > > 17.2. Root CA Certificate > > This section outlines the requirements for root CA certificates. We > should recommend SAN in my opinion. > > 17.2.1. Subject > > [RFC5280] mandates that Root CA certificates MUST have a non-empty > subject field. The subject field MUST contain the commonName, the > organizationName, and the countryName attribute and MAY contain an > organizationalUnitName attribute. > > > > Tschofenig, et al. Expires 21 April 2026 [Page 13] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 17.2.2. Authority Key Identifier > > Section 4.2.1.1 of [RFC5280] defines the Authority Key Identifier as > follows: "The authority key identifier extension provides a means of > identifying the public key corresponding to the private key used to > sign a certificate. This extension is used where an issuer has > multiple signing keys." > > The Authority Key Identifier extension MAY be omitted. If it is set, > it MUST NOT be marked critical, and MUST contain the > subjectKeyIdentifier of this certificate. > > mglt: Why not saying RECOMMENDED. > > 17.2.3. Subject Key Identifier > > Section 4.2.1.2 of [RFC5280] defines the SubjectKeyIdentifier as > follows: "The subject key identifier extension provides a means of > identifying certificates that contain a particular public key." > > The Subject Key Identifier extension MUST be set, MUST NOT be marked > critical, and MUST contain the key identifier of the public key > contained in the subject public key info field. > > The subjectKeyIdentifier is used by path construction algorithms to > identify which CA has signed a subordinate certificate. > > mglt: CABF mandates it. I think we should follow CABF. > > 17.2.4. Key Usage > > [RFC5280] defines the key usage field as follows: "The key usage > extension defines the purpose (e.g., encipherment, signature, > certificate signing) of the key contained in the certificate." > > The Key Usage extension MAY be set. If it is set, it MUST be marked > critical and the keyCertSign or cRLSign purposes MUST be set. > > mglt: CABF mandates KU. It is my belief we should follow these > recommendations. > > Additional key usages MAY be set depending on the intended usage of > the public key. > > [RFC5280] defines the extended key usage as follows: "This extension > indicates one or more purposes for which the certified public key may > be used, in addition to or in place of the basic purposes indicated > in the key usage extension." > > This extendedKeyUsage extension MUST NOT be set in CA certificates. > > > > > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 14] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 17.2.5. Basic Constraints > > [RFC5280] states that "The Basic Constraints extension identifies > whether the subject of the certificate is a CA and the maximum depth > of valid certification paths that include this certificate. The cA > boolean indicates whether the certified public key may be used to > verify certificate signatures." > > For the pathLenConstraint RFC 5280 makes further statements: > > * "The pathLenConstraint field is meaningful only if the cA boolean > is asserted and the key usage extension, if present, asserts the > keyCertSign bit. In this case, it gives the maximum number of > non-self-issued intermediate certificates that may follow this > certificate in a valid certification path." > * "A pathLenConstraint of zero indicates that no non-self-issued > intermediate CA certificates may follow in a valid certification > path." > * "Where pathLenConstraint does not appear, no limit is imposed." > * "Conforming CAs MUST include this extension in all CA certificates > that contain public keys used to validate digital signatures on > certificates and MUST mark the extension as critical in such > certificates." > > The Basic Constraints extension MUST be set, MUST be marked critical, > the cA flag MUST be set to true and the pathLenConstraint MUST be > omitted. > > > 17.3. Subordinate CA Certificate > > This section outlines the requirements for subordinate CA > certificates. > > 17.3.1. Subject > > The subject field MUST be set and MUST contain the commonName, the > organizationName, and the countryName attribute and MAY contain an > organizationalUnitName attribute. > > 17.3.2. Authority Key Identifier > > The Authority Key Identifier extension MUST be set, MUST NOT be > marked critical, and MUST contain the subjectKeyIdentifier of the CA > that issued this certificate. > > > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 15] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > 17.3.3. Subject Key Identifier > > The Subject Key Identifier extension MUST be set, MUST NOT be marked > critical, and MUST contain the key identifier of the public key > contained in the subject public key info field. > > 17.3.4. Key Usage > > The Key Usage extension MUST be set, MUST be marked critical, the > keyCertSign or cRLSign purposes MUST be set, and the digitalSignature > purpose SHOULD be set. > > Subordinate certification authorities SHOULD NOT have any > extendedKeyUsage. [RFC5280] reserves EKUs to be meaningful only in > end entity certificates. > > 17.3.5. Basic Constraints > > The Basic Constraints extension MUST be set, MUST be marked critical, > the cA flag MUST be set to true and the pathLenConstraint SHOULD be > omitted. > > 17.3.6. CRL Distribution Point > > The CRL Distribution Point extension SHOULD NOT be set. If it is > set, it MUST NOT be marked critical and MUST identify the CRL > relevant for this certificate. > > 17.3.7. Authority Information Access > > The Authority Information Access extension SHOULD NOT be set. If it > is set, it MUST NOT be marked critical and MUST identify the location > of the certificate of the CA that issued this certificate and the > location it provides an online certificate status service (OCSP). > > 17.4. End Entity Certificate > > This section outlines the requirements for end entity certificates. > > 17.4.1. Subject > > This section describes the use of end entity certificate primarily > for (D)TLS clients running on IoT devices. Operating (D)TLS servers > on IoT devices is possible but less common. > > > > > > > > Tschofenig, et al. Expires 21 April 2026 [Page 16] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > [RFC9525], Section 2 mandates that the subject field not be used to > identify a service. However, certain IoT applications (for example, > [I-D.ietf-anima-constrained-voucher], [IEEE-802.1AR]) use the subject > field to encode the device serial number. > > The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for > end entity certificates as a subject field is lifted. > > Two fields are typically used to encode a device identifier, namely > the Subject and the subjectAltName fields. Protocol specifications > tend to offer recommendations about what identifiers to use and the > deployment situation is fragmented. > > The subject field MAY include a unique device serial number. If the > serial number is included, it MUST be encoded in the X520SerialNumber > attribute. e.g., [RFC8995] use requires a serial number in IDevID > certificates. > > mgt: my understanding is thet X520SerialNumber is defined in 5280 and that > the use of serial in the subject. I think that it would be clearer if it > were indicated the attribute is in teh subject. Now, if teh serial numbe > ris an identifier, it shoudl eb placed in teh SAN as an URI in my opinion. > > [RFC5280] defines: "The subject alternative name extension allows > identities to be bound to the subject of the certificate. These > identities may be included in addition to or in place of the identity > in the subject field of the certificate." > > The subject alternative name extension MAY be set. If it is set, it > MUST NOT be marked critical, except when the subject DN contains an > empty sequence. > > If the EUI-64 format is used to identify the subject of an end entity > certificate, it MUST be encoded as a Subject DN using the > X520SerialNumber attribute. The contents of the field is a string of > the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the symbols > '0'-'9' or 'A'-'F'. > > Per [RFC9525] domain names MUST NOT be encoded in the subject > commonName. Instead they MUST be encoded in a subjectAltName of type > DNS-ID. Domain names MUST NOT contain wildcard (*) characters. The > subjectAltName MUST NOT contain multiple names. > > Note: The IEEE 802.1AR recommends to encode information about a > Trusted Platform Module (TPM), if present, in the HardwareModuleName > (Section 5 of [RFC4108]). This specification does not follow this > recommendation. > > Where IoT devices are accepting (D)TLS connections, i.e., they are > acting as a server, it is unlikely that there will be a useful name > that can go into the SNI. In general, the use of SNI for the purpose > of virtual hosting on constrained IoT devices is rare. The IoT > device cannot depend on a client providing a correct SNI, and so it > > > > Tschofenig, et al. Expires 21 April 2026 [Page 17] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > MUST ignore the extension. This implies that IoT devices cannot do > name-based virtual hosting of TLS connections. In the unlikely event > that an IoT device has multiple servers responding with different > server certificate, then the server SHOULD use different IP addresses > or port numbers. > > mglt: In the beginning SNI was mandated in TLS. > > 17.4.2. Authority Key Identifier > > The Authority Key Identifier extension MUST be set, MUST NOT be > marked critical, and MUST contain the subjectKeyIdentifier of the CA > that issued this certificate. > > 17.4.3. 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. 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. > > 17.4.4. Key Usage > > The key usage extension MUST be set and MUST be marked as critical. > For signature verification keys the digitialSignature key usage > purpose MUST be specified. Other key usages are set according to the > intended usage of the key. > > If enrollment of new certificates uses server-side key generation, > encrypted delivery of the private key is required. In such cases the > key usage keyEncipherment or keyAgreement MUST be set because the > encrypted delivery of the newly generated key involves encryption or > agreement of a symmetric key. On-device key generation is, however, > the preferred approach. > > As specified in [IEEE-802.1AR], the extendedKeyUsage SHOULD NOT be > present in IDevID certificates, as it reduces the utility of the > IDevID. For locally assigned LDevID certificates to be usable with > TLS, the extendedKeyUsage MUST contain at least one of the following: > id-kp-serverAuth or id-kp-clientAuth. > > 18. Update of Trust Anchors > > 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 > > > > Tschofenig, et al. Expires 21 April 2026 [Page 18] > > Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025 > > > anchors and not end entity certificates or certificates of > subordinate CAs. > > As an alternative, certificate management protocols like CMP and EST > have also offered ways to update trust anchors. See, for example, > Section 2.1 of [RFC7030] for an approach to obtaining CA certificates > via EST. > > 19. Certificate Overhead > > In a public key-based key exchange, certificates and public keys are > a major contributor to the size of the overall handshake. For > example, in a regular TLS 1.3 handshake with minimal ECC certificates > and no subordinate CA utilizing the secp256r1 curve with mutual > authentication, around 40% of the entire handshake payload is > consumed by the two exchanged certificates. > > Hence, it is not surprising that there is a strong desire to reduce > the size of certificates and certificate chains. This has led to > various standardization efforts. Below is a brief summary of what > options an implementer has to reduce the bandwidth requirements of a > public key-based key exchange. Note that many of the standardized > extensions are not readily available in TLS/DTLS stacks since > optimizations typically get implemented last. > > * Use elliptic curve cryptography (ECC) instead of RSA-based > certificate due to the smaller certificate size. This document > recommends the use of elliptic curve cryptography only. > * Avoid deep and complex CA hierarchies to reduce the number of > subordinate CA certificates that need to be transmitted and > processed. See [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] for > a discussion about CA hierarchies. Most security requirements can > be satisfied with a PKI depth of 3 (root CA, one subordinate CA, > and end entity certificates). > > mglt: with AIA do we really need to have the full chain as the receiver > with sufficient resources may get the chain from the CA. no ? > > > > On Fri, Oct 31, 2025 at 11:40 AM Renzo Navas <[email protected]> wrote: > > Hi All, > > I am the shepherd of this document. > Just a friendly reminder for @Daniel: > can you take a look at the modifications for the authors? > Do they mostly address your comments? > > If that is the case, (now I am speaking for the WG Chairs), we will be > able to move forward in the procedure, right? > > See you in Montreal maybe (I will be attending physically) > > Regards, > > Renzo > > > > On Sat, Oct 18, 2025 at 12:24 PM Tschofenig, Hannes > <[email protected]> wrote: > > > > Hi Daniel, > > > > > > > > We have just submitted a new version of the “TLS/DTLS 1.3 Profiles for > the Internet of Things” draft. > > > > This specification update was in the result of your detailed review, > Daniel. > > > > > > > > In response to the review MCR has identified more than 30 issues, which > he captured in the Github repo at > https://github.com/thomas-fossati/draft-tls13-iot/issues > > > > > > > > Responses are captured in the respective issues. Daniel, please have a > look and see whether you are satisfied with the response and the updated > text in the draft. (I copied text for most of issues into the Github issue > page directly for easier processing). > > > > > > > > Your review has certainly improved the quality of the write-up. Thanks! > > > > > > > > Ciao > > > > Hannes > > > > (On behalf of the authors) > > > > _______________________________________________ > > Uta mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > > -- > > Daniel Migault > > Ericsson > > > > _______________________________________________ > > Uta mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
