Hi Michael, > TL;DR> Help us avoid stuffing non-DNS strings into > SubjectAltName dNSName when doing device to device (D)TLS.
I may fail to understandiung your question or intention. Maybe you clarify it. Your initial question in "draft-tls13-iot" was: "I was looking for a SN, or SAN that would encode EUI64, and I feel surprised not to find one." But, if you like to encode a EUI64 direct in x509 SN or SAN without "translation", then I would guess, this is a question for RFC 5280 [1] (and updates) and not for "draft-tls13-iot". Or do you want to use NOT the EUI64 in device certificates? Then in "If the EUI-64 format is used to identify the subject of an end entity certificate, it MUST be encoded in a subjectAltName of type DNS-ID as 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'." the leading "if" will help you to escape it. So, please: Is it about direct EUI64 support in x509? Or about omit EUI64 in device certificates? br Achim [1] https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.6 Am 06.01.25 um 20:29 schrieb Michael Richardson:
Please note and respect the Reply-To: u...@ietf.org. TL;DR> Help us avoid stuffing non-DNS strings into SubjectAltName dNSName when doing device to device (D)TLS. In https://github.com/thomas-fossati/draft-tls13-iot/issues/65 I ask why draft-ietf-uta-tls13-iot-profile suggests that IoT devices that have certificates (probably IDevID) whose primary identity is an EUI64 are using dNSName with a fabricated ascii representation of hex EUI64. (An EUI64 identity is often common on 802.15.4 networks, which use 8-byte EUIs) now at: https://www.ietf.org/archive/id/draft-ietf-uta-tls13-iot-profile-11.html#name-subject-3 we say:When the server identity is given by an EUI-64 format, then it MUST be encoded in a subjectAltName of type DNS-ID {{RFC9525, Section 1.5}}, as 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'.and some of this goes back to RFC7925. Section 4.4.1 says: Note that there will be servers that are not provisioned for use with DNS domain names, for example, IoT devices that offer resources to nearby devices in a local area network, as shown in Figure 7. When such constrained servers are used, then the use of certificates as described in Section 4.4.2 is applicable. Note that the SNI extension cannot be used in this case since SNI does not offer the ability to convey a 64-bit Extended Unique Identifier (EUI-64) [EUI64]. Note that this document does not recommend use of IP addresses in certificates nor does it discuss the implications of placing IP addresses in certificates. and also: 4.4.2. Certificates Used by Clients For **client certificates**, the identifier used in the SubjectAltName or in the leftmost CN component of subject name MUST be an EUI-64. (I find the above very unclear btw. So at least the text from the update is better) ---- Note: DNS-ID is not a SAN, but rather through indirection through RFC9525 section 1.5: DNS-ID: A subjectAltName entry of type dNSName as defined in [PKIX]. I really don't want to encode new sillyness into dNSName!!! We really *ought* to be using otherName. Some years ago I wrote code that did that, using a PEN OID in otherName with mbedtls. {I suspect that any savings from encoding the 8-byte EUI64 in binary (vs 16+7 ascii bytes) is probably lost due to the OID needed in the otherName. But I didn't count yet} I think that otherName:<OID-to-be-allocated> ought to be fine for all uses where a certificate is used for client-side TLS authentication to a "cloud" service. Such a service will be referenced by (DNS) name, and so an SNI belongs. Where we get into trouble is when we want to do device to device communication such as with COAPS (CoAP over DTLS). If there has not been an onboarding process that has deployed an LDevID, then we miight wind up using that same IDevID certificate. This all assumes: 1) the IoT device is acting as a (D)TLS endpoint. {such as CoAPS!} 2) the IoT device is using EUI-64 as it's identity (vs having an LDevID assigned) 3) there are more than one (D)TLS endpoint on the device, making an accurate SNI important while for class 2 or lower devices, the odds of the device having more than one valid TLS endpoint is low, for class 4,10,15[RPI] devices, it seems entirely reasonable that there could be multiple end-points distinguished by SNI. options that I see are: 1. hold my nose (and yours) and standardize this. 2. declare multiple end-points requiring SNI to be out-of-scope, and so (D)TLS servers on such devices should ignore SNI, and clients shouldn't bother putting in anything that isn't a real name. (It could well be "printer.local"!) 3. declare that multiple end-points would require an onboarding process (BRSKI, Matter, OPC-UA, EAP-TEAP-BRSKI, ...) to replace any IDevID with otherName:EUI64 identity with a proper name that would fit into SNI. 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI. There isn't an IANA registry for this. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Uta mailing list -- u...@ietf.org To unsubscribe send an email to uta-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
