Working off of https://www.ieee802.org/secmail/msg00396.html
EUI-MAC-OtherNames-2025 { iso(1) identified-organization(3) dod(6)
internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-eui-mac-othername-00
(tbd0)}
DEFINITIONS
BEGIN
IMPORTS
OTHER-NAME FROM PKIX1Implicit-2009 { iso(1) identified-organization(3)
dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
id-on-eui48 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) tbd1 }
id-on-eui64 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) tbd2 }
id-on-mac48 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5)
mechanisms(5) pkix(7) on(8) tbd3 }
Eui48 ::= OCTET STRING SIZE(6)
Eui64 ::= OCTET STRING SIZE(8)
Mac48 ::= OCTET STRING SIZE(6)
on-eui48 OTHER-NAME ::= { Eui48 IDENTIFIED BY id-on-eui48 }
on-eui64 OTHER-NAME ::= { Eui64 IDENTIFIED by id-on-eui64 }
on-mac48 OTHER-NAME ::= { Mac48 IDENTIFIED by id-on-mac48 }
END
or use on-hardwareModuleName.
I agree with Michael 100% that using "fabricated ascii" to represent an
EUI (or mac) of either type in PKIX related items is generally a bad idea.
On 1/6/2025 2:29 PM, Michael Richardson wrote:
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
_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org
_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org
