Re: [OPSAWG] [Anima] dealing with multiple manufacturer services with a single certificate extension

[Michael Richardson <[e-mail]>]

I've read through the thread.  It took more brain-power that I've had
available of recent.

Let me ask some clarification questions about the original proposal.

I generally agree with Max that the /.well-known/ part can be omitted.

I also prefer passive (static file) initial interactions so that
the initial contact point can be most easily maintained over a period of
decades.  I was surprised when some proprietary uses like this would point at
the www.example.com, rather than something more divorced from marketing,
like a "bootstrap.example.com".

So I rather like the mfg-services reply which is essentially a redirect
which can be updated over the years.


> https://example.com/.well-known/mfg/modelname
>
> which would return something like:
>
>{
>   "mfg-services" : [
>     "mud", "v1", "https://mud.example.com/Frobmaster3000.json",
>     "anima", "v1", "https://masa.example.com/masa-service"
>   ]
>}

correct?   In this case, the modelname is there to distinguish phones
From printers from home-routers, which might well be very separate
divisions.

> At the moment, more manufacturers are coming back to me to say that we
> should just leave these as separate and distinct mechanisms. I think that's
> the simplest approach.

Distinct mechanisms, but common certificates?  Or distinct certificates?


> It seems to me the simplest way to handle this sort of thing is to create a
> table that MUD/ANIMA controllers simply download when they see the URL. It
> might look something like this:

When you say ANIMA controller, I think you mean the JRC?



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