Hi, all, We are updating the IoT profile draft and wanted to gather some input on the following three topics:
1. Reliance on SW updates for certificate status information instead of CRLs and OCSP 7925 Section 4.4.3 says: For certificate revocation, neither the Online Certificate Status Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. Instead, this profile relies on a software update mechanism to provision information about revoked certificates. This still looks like a sensible approach, but it's worth checking whether practice has deviated from the assumption. If so, it's also probably better to strengthen it a bit and make it an explicit recommendation. 2. Requirements on serial number randomness 7925 Sec. 4.4.4 (Table 1) has: serialNumber | Positive integer unique per certificate. which is a bit too terse (is it unique within a given CA? If so, this is vanilla 5280 which is probably not worth restating) and, most importantly, it says nothing about entropy. Should we have something here about recommending at least 64 bit, similar to the CA/B baseline requirements? 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? We should drop the MUST as it doesn't make a lot of sense to constrain a deployment WRT to its naming conventions. Besides, other standards have emerged or gained traction in the IoT space that require populating the SAN differently (e.g., GSMA eUICC uses registeredID, IEEE DevID uses otherName of type hardwareModuleName). Let us know. We plan to incorporate any feedback and submit a new version in the next couple of weeks. Cheers, thank you very much! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
