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

[Michael Richardson]

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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Eliot Lear]

Hi Max,


On 4/24/17 5:52 PM, Max Pritikin (pritikin) wrote:
>
> I’ve been agitating for a combined form. My thanks to Eliot for
> continuing the conversation. Below I provide some details from the
> current BRSKI draft to flesh out the conversation and then present an
> argument for my position.
>
>> On Apr 23, 2017, at 5:23 AM, Eliot Lear > > wrote:
>>
>> Hi everyone,
>>
>> Just a quick update on this document.  I am preparing for the next
>> version of the draft.  There is one major change contemplated that is
>> not yet addressed.
>>
>> I received feedback from the IETF Chicago meeting regarding how best
>> to structure URLs in manufacturer certificates.  There are currently
>> two planned, one for MUD and one for ANIMA/BRSKI.  The question is
>> whether these should be combined. 
>>
>> I had said in Chicago that I would ask various manufacturers about
>> whether additional complexity on the backend is worth saving the
>> bytes in the certificate.  There was, as you might imagine, a mixed
>> response.  A number of manufacturers answered, “No, and in fact we
>> want to do our own certificate extensions”.  Others simply answered
>> “No, the code requirements for ANIMA will probably make the cert
>> extension a relatively minimal matter”.  And some manufacturers,
>> said, “yes, every byte counts.”  I am proceeding in a way that
>> accommodates the 3rd group for now, but I seek discussion.
>>
>> If we combine the URLs the way it would work is that there would be a
>> service endpoint along the lines of the following:
>>
>>   * https://example.com/.well-known/mfg/modelname
>>
> Given that the .well-known concept is already well defined the
> approach taken in the BRSKI draft (s2.3) is to include only the
> “manufacturer” authority:
> https://example.com
>
> From here the relying party can use the .well-known constructs to
> access any variety of manufacturer services which I expect to include 
> https://example.com/.well-known/brksi
> https://example.com/.well-known/mud
> etc
>
> This minimizes the information stored within the certificate itself. A
> single extension indicating the “manufacturer services authority”.
> Building a full URL to these services is done using the .well-known
> method.

One challenge here is that we need model information present, and you
may need it as well to route to the correct BRSKI service (presuming
there is more than one for manufacturer example.com).  And so we would
need to add at least the model back, or otherwise reflect the model in
the authority section.  I'm not a big fan of requiring that because it
requires unnecessary interactions with DNS administration.

>> At that point, we would need to deference, introducing some
>> additional complexity somewhere in the system.  We should be mindful
>> of the following issue:
>>
>>  1. Versioning should be supported OUTSIDE of the referenced
>> service.  The more that is done, the more freedom the referenced
>> service has the ability to change.
>>  2. Versioning of services should not be done in lock step.  That is,
>> if we keep the versioning information in the URL, that means that
>> when the MUD version is bumped, so too would the ANIMA version. 
>> It is possible to keep a registry that would indicate URL
>> versioning and then map to all the different versions of whatever
>> is referenced, but that seems ridiculously complex.
>>  3. The resolution mechanism to services should be independent of how
>> the URL is gotten by the various {MUD/ANIMA/...} controllers. 
>> And thus, if a MUD controller receives the URL via LLDP or DHCP,
>> the same processing should occur as if it was received via a
>> certificate.  This simplifies code paths, and will hence reduce
>> risk of bugs.  It will also follow the principle of least
>> astonishment.
>>
>> 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:
>>
>> {
>>"mfg-services" : [ 
>>  "mud", "v1", "https://mud.example.com/Frobmaster3000.json;,
>>  "anima", "v1", "https://masa.example.com/masa-service;
>>]
>> }
> Using a .well-known to query a host about which possible interfaces
> are available has precedent. For an alternative example also see,
> https://tools.ietf.org/html/rfc6415
> "The client obtains the host-meta document for a given host by sending
>   an HTTP [RFC2616 ] or an HTTPS 
> [RFC2818 ] GET request to the host for
>the "/.well-known/host-meta” path […]”
>
>
> I see this as an optional redirection that MUD or BRSKI or future
> protocols might define but don’t see it as a necessary part of the
> manufacturing certificate extension definition. I’d think we could
> stop at an extension to provide the root authority to form .well-known
> URLs. 

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

[Eliot Lear]

Hi everyone,

Just a quick update on this document.  I am preparing for the next
version of the draft.  There is one major change contemplated that is
not yet addressed.

I received feedback from the IETF Chicago meeting regarding how best to
structure URLs in manufacturer certificates.  There are currently two
planned, one for MUD and one for ANIMA/BRSKI.  The question is whether
these should be combined. 

I had said in Chicago that I would ask various manufacturers about
whether additional complexity on the backend is worth saving the bytes
in the certificate.  There was, as you might imagine, a mixed response. 
A number of manufacturers answered, “No, and in fact we want to do our
own certificate extensions”.  Others simply answered “No, the code
requirements for ANIMA will probably make the cert extension a
relatively minimal matter”.  And some manufacturers, said, “yes, every
byte counts.”  I am proceeding in a way that accommodates the 3rd group
for now, but I seek discussion.

If we combine the URLs the way it would work is that there would be a
service endpoint along the lines of the following:

  * https://example.com/.well-known/mfg/modelname

At that point, we would need to deference, introducing some additional
complexity somewhere in the system.  We should be mindful of the
following issue:

 1. Versioning should be supported OUTSIDE of the referenced service. 
The more that is done, the more freedom the referenced service has
the ability to change.
 2. Versioning of services should not be done in lock step.  That is, if
we keep the versioning information in the URL, that means that when
the MUD version is bumped, so too would the ANIMA version.  It is
possible to keep a registry that would indicate URL versioning and
then map to all the different versions of whatever is referenced,
but that seems ridiculously complex.
 3. The resolution mechanism to services should be independent of how
the URL is gotten by the various {MUD/ANIMA/...} controllers.  And
thus, if a MUD controller receives the URL via LLDP or DHCP, the
same processing should occur as if it was received via a
certificate.  This simplifies code paths, and will hence reduce risk
of bugs.  It will also follow the principle of least astonishment.

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:

{
   "mfg-services" : [ 
 "mud", "v1", "https://mud.example.com/Frobmaster3000.json;,
 "anima", "v1", "https://masa.example.com/masa-service;
   ]
}

This sort of change would be required in both the ANIMA and MUD
services, but could then be used for any other manufacturer-based
service.  Is this what people want?  For MUD, this amounts to a simple
additional file retrieval.  For ANIMA, the same.  Then one simply
dereferences the table.  Most importantly, all implementations need to
be prepared to handle the case where a particular service is NOT listed
(this might seem like a big duh, but I figured I'd mention it).

Comments?

Eliot



signature.asc
Description: OpenPGP digital signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima