[Uta] IoT profile - input needed

[Thomas Fossati <[e-mail]>]

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.