Subject: Re: [Iotops] can we create protocols that securely transfer ownership?

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Nov 2020 10:56:08 -0500

Alexandre Petrescu <[email-masked]> wrote:
    > 'Transferring ownership' - like in selling property to somebody?  A
    > contract would be needed, and a notary with an electronic signature.

The notion of a third-party witness to attest to the transfer is definitely
important.

    > In these worlds indeed the person-to-person communication would be
    > needed to avoid negative situations.  But 'transferring ownership' would
    > not be desirable: one would not transfer ownership of information from
    > one's brain to Things and even less let these Things further
    > transfer ownership to other private interests.  There would be a need of
    > a protocol to make sure ownership is not transferred, but hardcoded in
    > silicium.

I suspect that you don't understand the term, or that it didn't translate
well for you.

The point is when you sell your car to me, that it ceases to be your car, and
is now, only, my car.

When you buy a house, the first thing you do is change all the locks.
When you lease/rent a house, you don't.  The landlord retains a copy of the key.

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Nov 2020 12:55:53 +0000

On 31-Oct-20 06:25, Michael Richardson wrote:
> 
> Andrew G. Malis <[email-masked]> wrote:
>     > Yes, in addition to being a good story, the point is who controls the
>     > firmware in our things, and how bad it can get not only when the
>     > manufacturer enforces DRM, but the gov't enables the behavior
>     > (criminalizing jailbreaking).
> 
>     > Or the issues that arise when the manufacturer fails to properly maintain
>     > the firmware, or goes out of business.
> 
> All major concerns.  What do you think the IETF can/should do?
> I have some very specific ideas which I think are manageable and specific.

Both BRSKI and SUIT have minor references to the latter problem, and I
think that when considering tiny cheap devices it isn't a theoretical issue,
but one that's highly likely. There is also (as for incandescent light
bulbs) a strong incentive for manufacturers to sell devices that are
designed to break after a while. An expiring certificate would be a great
way to break devices remotely, for example.

[Qin]: Indeed, if someone can tamper the clock and change system clock
Into one past time before the expiring date of the certificate, that means
the certificate duration is extended. How do we deal with this issue?

Similar issue is applicable to software license expiring.

   Brian