Re: [Danish] Charter Text and the Problem Statement

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

I was not necessarily thinking about IEEE 802.1AR and the way BRSKI uses it. BRSKI is kind of special in the way it is designed.

In general, in security there is the idea to use different keys for different purposes. If that has changed then I completed missed it.

Regarding the management of access with wearables and smart home deployments using standardized protocols I thought that this is why we did all the work in ACE.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[e-mail]>
Sent: Monday, June 21, 2021 4:41 PM
To: Hannes Tschofenig <[e-mail]>; [e-mail]
Subject: Re: [Danish] Charter Text and the Problem Statement


Hannes Tschofenig <[e-mail]> wrote:
    >> If you use DANISH, then you don't need to onboard the device
    >> (i.e. enroll it with a new certificate), because you already have secure
    >> access to the correct certificate via DNS(SEC).

    > In the past we used different keys for different purposes. A
    > manufacturer provided key was used for a relatively small number of
    > tasks (typically for obtaining operational keys). For use with
    > application services we used a different key. We used yet another key
    > for firmware updates and again another for attestation.

    > What has changed?

As you know I'm a big proponent of using an IDevID with an onboarding protocol to obtain an LDevID.
I think that this is still an important path.  But, it's not the only path!

While I think your next comment might be about divergent paths causing market
confusion,  I think that we are already there.   There are presently a number
of incompatible systems out there that deliver keys from the factory to be used in production.

I think that the DANISH might be an interesting way to publish *LDevID*s.
While I might onboard a device into my network, in the future, imagine that different operational networks might need to interact without having an ownership relationship.  For instance, any personal wearables you might have interacting with a variety of building or vehicle systems that you are in.
How will I give you permission to turn on the lights in my house?
I'd surely prefer to list that authorization by DNS name, rather than hash, right?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [




--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




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.