Hi, I think it would be good if the draft gave a recommendation on how to format the EUI-64. My feeling from googling all the specification I could find is that the most common way to format a EUI-64 as a text string is with dashes and with capital hex characters. This is what is currently optimized in the COSE work on CBOR certificates.
https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-06 "If the text string contains an EUI-64 of the form "HH-HH-HH-HH-HH-HH-HH-HH" where 'H' is one of the symbol '0'-'9' or 'A'-'F' it is encoded as a CBOR byte string of length 8 instead. EUI-64 mapped from a 48-bit MAC address (i.e. of the form "HH-HH-HH-FF-FE-HH-HH-HH) is encoded as a CBOR byte string of length 6." If UTA has some other view, I would be happy to hear about it. ---- Ben, the secdispatch seems to be for servers. I think there is quite a big difference between servers and clients. For IoT devices I think putting a EUI-64 in CN is quite common. ---- I think be good it the validity text is reworded. In RFC 7925 it says: "Values expressed as UTC time in notBefore and notAfter fields. No validity period mandated." This is to my knowledge not different from RFC 5280 as "UTC time" = Zulu = GMT. If RFC 7925 mean "UTC time", the text actually causes confusion as "UTC time" is easily confused with "UTCTime". If RFC 7925 mean "UTCTime" is probably time to allow GeneralizedTime. Cheers, John -----Original Message----- From: Uta <uta-boun...@ietf.org> on behalf of Benjamin Kaduk <ka...@mit.edu> Date: Thursday, 11 February 2021 at 21:10 To: "uta@ietf.org" <uta@ietf.org> Subject: [Uta] IoT profile - input needed On Thu, Feb 11, 2021 at 12:00:10PM -0800, uta-requ...@ietf.org wrote: [...] > 3. Requirements on cert naming > > RFC 7925 Sec. 4.4.2 says: > > For client certificates, the identifier used in the SubjectAltName or > in the leftmost CN component of subject name MUST be an EUI-64. > > This looks problematic as it's at the same time too rigid - the MUST > doesn't permit deviation - and too loose, glossing over the details of > how the EUI-64 is actually encoded. > > When used in the CN, i.e., as printable string, it looks like it's > sensible to assume that the IEEE guidelines for EUI-64 apply (the usual > "01-23-...-cd-ef" or "0123...cdef"), and that might be the case for the > SAN as well, stuffing it into a dNSName. > > Does that sound reasonable? Are you aware of any other practice? Mention of CN stuck out to me -- the trend seems to be towards just not using CN at all -- see the secdispatch request for a draft at https://mailarchive.ietf.org/arch/msg/secdispatch/TAk5H3u_5C_JehUB7EKAnfegxj0/ -Ben _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
