Re: [Dtls-iot] IP Addresses in Certificates

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> quoted (I think) Stephen Farrel
as saying:
    > (5) 6.3: Forgetting CoAP for the moment, surely this profile will be
    > used with devices that only have (possibly bogon) IP addresses and that
    > want to have those in certs. I do get that how to handle that well is
    > not very clear, esp. for certs for e.g. 192.168.0.1, but shouldn't it
    > really be covered by this profile?

  Hanness> https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-01

Reading this document....

I think that is indeed a must have document.
Let's take this out of the IoT space for a moment.

Ever turned on a Dell/HP/IBM/Supermicro server that has an "Integrated Lights
Out"/iDrac/ServiceProcessor/IPMI interface?  Basically this is a small
embedded system on the motherboard that speaks http(s), and lets' you manage
the server remotely.  There are is also APIs into it, and you can do things
like install the machine, reboot it, etc.

Such systems could easily come with a built-in "Manufacturer Installed
Certificate" (aka "MIC", which is sadly, a really confusing TLA), except that
the machine will almost always be addressed by IP address, which will either
be SLAAC or RFC1918, and will seldom ever have a name ever, and certainly
won't have a name when first installed.

I see section 3.2.3 would let one have a SubjectAltName that looks like:
  eui-64+01-23-45-67-89-ab-cd-ef

or, I guess equally:
  eui-48+00-28-21-a7-5e-27

if my browser location tab were to say
   https://[somemagicsyntax/eui-48+00-28-21-a7-5e-27]
then we could dispense with a bunch of inappropriate security warnings.

Your document would help very much.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-