Subject: Re: [Iotops] maintain ownership (was: can we create protocols that securely transfer ownership?)

From: Qin Wu <[email-masked]>
Date: Tue, 3 Nov 2020 13:32:29 +0000

On Sat, Oct 31, 2020 at 08:58:27AM +1300, Brian E Carpenter wrote:
> On 31-Oct-20 06:25, Michael Richardson wrote:
> >
> > Andrew G. Malis <[email-masked]<mailto:[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.

Indeed, before even thinking about transferring ownership i would to see what
IETF security community can do to remove the current problem of even just
MAINTAINING OWNERSHIP in face of (if i am not mistaken) current PKI
recommendations:

My TivoHD for example had its certificate expire few years into its lifetime,
even though i had upfront bought a so-called "lifetime service" for it.
Of course, the lifetime-service did not include "maintaining a current cert for the
lifetime of the device".

And that is just the most egregious example i ran across because of me having
to learn how to hack up all the software that was talking to the TiVo via
TLS - to ignore the expired cert.

I am saying the IETF is partially to blame because i think we also proliferate
the notion that certificates have to be renewed periodically with maximum
usual lifetimes of now i think one year ? (was two years)

Of course, this is specifically a consumer-IoT problem, because industrial
customers should typically be in a stronger position to avoid these vendor
abuse of principally sound technical guidance.

As much as i like to explore short lived certificates more in environments
where i can set up the right environment to support that, we should IMHO
also think about the simplicity of lifetime-long-certificates. Which we
currently do not have in web PKI.

The fact alone that we do only have in browsers one single TA space (Internet)
seems to be the worst offender, proliferated by the fact that that is the
only domain that most big contributors in the IETF are interested in.
Nevertheless, to support what we classically did without crypto, namely
private networks (with private addresses), we should also have a crypto
strategy for such private networks. And in most cases, lifetime-long certs
will be the only reasonable solution there.

But, and to get back to the topic: One way on how to get to lifetime-long
certs would be an actual transfer of ownership from whaever the vendor
put in as certs to a cert from the current owner and using a lifelong
expiry time (e.g.: infinite). This could be hosted in a private TA.
The question is primarily how to have browsers support different TA
domains without confusing the user.

And of course, when you sell the device, you would need to do transfer
of ownership again by overwriting the current cert with one of the
new owner.
[Qin]: Not sure lifetime long certs is a good idea. I feel it is more vulnerable.
Also I think the current cert doesn't need to be overwritten by cert of the new owner.
The current Cert can be embedded in the Cert of new owner, see delegation voucher
https://tools.ietf.org/html/draft-richardson-anima-voucher-delegation-02
when the device is in resale, wrong?

JUst a line of thoughts.

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Nov 2020 14:01:25 -0500

>> way to break devices remotely, for example.

Toerless => tte wrote:
   tte> Indeed, before even thinking about transferring ownership i would to see what
   tte> IETF security community can do to remove the current problem of even just
   tte> MAINTAINING OWNERSHIP in face of (if i am not mistaken) current PKI
   tte> recommendations:

   tte> My TivoHD for example had its certificate expire few years into its lifetime,
   tte> even though i had upfront bought a so-called "lifetime service" for it.
   tte> Of course, the lifetime-service did not include "maintaining a current cert for the
   tte> lifetime of the device".

What did the certificate do?
Was this part of an HTTPS management system, or did it allow it to connect
back to some cloud service?

   tte> And that is just the most egregious example i ran across because of me having
   tte> to learn how to hack up all the software that was talking to the TiVo via
   tte> TLS - to ignore the expired cert.

   tte> I am saying the IETF is partially to blame because i think we also proliferate
   tte> the notion that certificates have to be renewed periodically with maximum
   tte> usual lifetimes of now i think one year ? (was two years)

That's not the IETF making this policy, this is the CABForum.org, and this is
driven mostly be browser manufacturer.  All security is a circle.

   tte> Of course, this is specifically a consumer-IoT problem, because industrial
   tte> customers should typically be in a stronger position to avoid these vendor
   tte> abuse of principally sound technical guidance.

You'd think so.
The IETF can't really fix specific problems, but what we can do is provide
names for processes that allow people/enterprises to take ownership of their
devices.

   tte> The fact alone that we do only have in browsers one single TA space (Internet)
   tte> seems to be the worst offender, proliferated by the fact that that is the
   tte> only domain that most big contributors in the IETF are interested in.
   tte> Nevertheless, to support what we classically did without crypto, namely
   tte> private networks (with private addresses), we should also have a crypto
   tte> strategy for such private networks. And in most cases, lifetime-long certs
   tte> will be the only reasonable solution there.

I am imagining a IoT-specific browser.
It would have a different set of trust anchors.
It would NEVER be able to talk to facebook or your bank.
It would instead have a set of IoT trust anchors, and/or a federation of
them.
At this level, it can probably be done as a browser profile without changing much code.
(The 382 day limit seems to not apply to additional trust anchors)

Where we get into trouble, I think, is where you need to load content from
multiple places.
For instance, what if your device references jQuery from a CDN?
What if you want to use OAUTH2 to login to your device as authorized by a
cloud system?

We don't have Cu (CoAP support)in Firefox anymore, because one can't write
new schemes as extensions due to security architecture changes.

   tte> But, and to get back to the topic: One way on how to get to lifetime-long
   tte> certs would be an actual transfer of ownership from whaever the vendor
   tte> put in as certs to a cert from the current owner and using a lifelong
   tte> expiry time (e.g.: infinite). This could be hosted in a private TA.
   tte> The question is primarily how to have browsers support different TA
   tte> domains without confusing the user.

I was thinking about this, and I come back to wondering if one thing that
could be done is to have a completely different scheme for IoT devices.
It would be "https", but with different rules about how it may reference
other resources.   To first order, COAPS does this, but not exactly.

On my desktop, I use chrome for most things, but I use a specific firefox
profile for banking and financial matters.   I think that we need more of
this: the various "incognito" moves go one direction (removing identity and
interaction for certain transactions).
We need another direction, super-cognito mode, where additional identity
information is available.   But, then we also need lateral movements,
where I can substitute my "work" identity easily for my "home owner" identity.

   tte> And of course, when you sell the device, you would need to do transfer
   tte> of ownership again by overwriting the current cert with one of the
   tte> new owner.

Qin Wu <[email-masked]> wrote some comments:

   Qin> Not sure lifetime long certs is a good idea. I feel it is more
   Qin> vulnerable.

   Qin> Also I think the current cert doesn't need to be overwritten by cert
   Qin> of the new owner. The current Cert can be embedded in the Cert of new
   Qin> owner, see delegation voucher

The delegation voucher provides a history of ownership.
But, that isn't the device's certificate, it's the manufacturer's statement.
I don't see how we can use delegated-voucher to augment the LDevID, except by
replacing it.

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Nov 2020 20:09:06 +0100

Thanks, Qin

Cross-posting to anima, because i think these discussions apply to any type
of (physical) device level certificate wrt. ownership:

Most IDevID in TPMs can not be renewed, so they either have infinite lifetime,
or the device is preordained trash when the certificate expires. 

The security problem you are pointing to is called key exhaustion, aka: it
does not come from the lifetime, but from how often you use it. One
simple way to solve this is not to use such infinite lifetime certs often.
This is true for IDevIDs unless you start to do bad protocols that use them
often.

One simple way IMHO to solve this problem is to make the infinite lifetime
certs a local CA and use it to periodically generate new local cert(s) that
you use actively. Increases amount of data for cert-chain signaling required though.

Wrt. overwriting existing certs: i was just giving an example. Agree that there
are various options.

Cheers
    Toerless

On Tue, Nov 03, 2020 at 01:32:29PM +0000, Qin Wu wrote:
> Iotops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iotops

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 3 Nov 2020 21:48:23 +0100

> back to some cloud service?

I don't know whether or not it was used to connect to the cloud service. I would
assume it didn, i should have wiresharked this. It was used for (legal, TiVO permitted ;-)
https download of recordings, so the box became logically unusable for the intended
purpose (download recordings for watching later on a different device).

> driven mostly be browser manufacturer.  All security is a circle.

IETF also had its own opinion about X.5xx and those standards RFC are now
industry standards overriding X.5xx, so why not about this lifecycle managment ?
something like iotops would be a possible place to do this for such type of
consumer/... devices. But not precluding other IETF WG.

> names for processes that allow people/enterprises to take ownership of their

Right. Process / proces-profile BCP.

Remember my slides showing Homer Simpson as the registrar ? That level of
abstraction process definitions might help (if need be without home ;-)

> It would instead have a set of IoT trust anchors, and/or a federation of

Yes, different TA realms is a very good design starting points for different
network domains that need to be isolated from each other at the end-to-eend layer.

Whether is a same browser or new tabs (white=internet, black=internet-"anonymous",
red="private-network") is IMHO secondary. I do agree though that a browser
for a lot of iot management cases could be a lot smaller than an Internet browser,
so it would fit itself easier into embedded devices itself and be a lot more
reliable and predictable in its page rendering than all the horrenduously
complex options-galore W3C has produced for "The Internet TA realm".

> multiple places.  > For instance, what if your device references jQuery from a CDN?

I for once would appreciate if my home gateway would be a TLS proxy that can
see the actual payload passed between my home IoT devices and the cloud. Especially
to allow ME to PERVASIVELY MONITOR what all those iot devices do to the cloud.
Aka: Only this monitoring/filtering TLS proxy would be given TA to both realms
on either side. I am quite certain that most if not all of industrial device
security policies would expect to have an equivalent level of security policy
rquirements. Just the protocols (TLS) would be different for them. Like at
least 20 variations of MQTT brokers instead of TLS proxies or the like.

I highlighted specific words because i think iot operations in IOT will get nowhere
unless it becomes clear that such functions are mandatory for many iot use cases,
and i can't wrap my head around why not every contributor already sees them as
crucial for their own personal use of networking.

The iotops charter for example also does not talk about data management for
iot devices. This type of security operations would fall into that type
of charter point.

> new schemes as extensions due to security architecture changes.

Ok, i don't get that.

> other resources.   To first order, COAPS does this, but not exactly.

Somebody more tortured by the variety of iot relevant device to cloud protocols
should give an overview of all the stuff that will stay relevant and would
be within scope of IETF. I would suspect that https/coap are reall just a
smaller subset of what is relevant, so for a BCP or process document it
would initiallybe more important to identify those protocols and see what scheme
of evolution for multiple TA realms might equally work across them instead
try to figure out a one-off solution for one protocol. Of course, experimentation
on any individual protocol is highyl welcome, it just shouldn't be taken
as a suggested general principle unless we know it can map to other protocols.

> interaction for certain transactions).

Yepp. And with those huge browser we have today, i would really like to
use something like containers to create disjoint running instances with safely
isolated-from-each other profiles. Instead of trusting the browsers to keep
those profiles apart.

Alas, never started to see how difficult it would be to install multiple
instances of e.g. chrome via docker. But foremost one would need a way
to sufficiently influence look&feel of each instance to be differnt
(color scheme of borders or the like).

> where I can substitute my "work" identity easily for my "home owner" identity.

IN L3VN we developed the notion of RD and RT to express partial overlap
of "reachability". I am sure if we want to shoot ourselves security wise into
the feet with complex partially overlapping TA realms/imports into context
and the like, we can steal a lot from L3VPN ;-))

> I don't see how we can use delegated-voucher to augment the LDevID, except by

When we discussed BRSKI and change of ownership in the past years it was
always mitigated through the MASA and therefore vendor. I think that is an
important option. I would like to see the option of being able to do this without
any vendor/MASA involvement of course too. I don't think it would be a problem to
define suh a process, but i really would prefer we would define those
workflows abstract first so they're not stuck in a specific protocol like BRSKI,
but could more esily be proliferated across various protocols faster.

aka: for the least difficult to implement "sell-on-ebay" option, you as the
outgoing owner could create a bearer token, and send that in email to the ebay buyer and in parallel
ship the product. Then the receiving new owner could take ownership. But the
vendor should not be able to dis-own the product unless you as the owner
explicitly create a bearer-token.   --- just as an example.

A device could keep track of prior owner LDevID/TA or not ... different issue.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 13:30:09 -0500

Toerless Eckert <[email-masked]> wrote:
    >> What did the certificate do?  Was this part of an HTTPS management
    >> system, or did it allow it to connect back to some cloud service?

    > I don't know whether or not it was used to connect to the cloud
    > service. I would assume it didn, i should have wiresharked this. It was
    > used for (legal, TiVO permitted ;-) https download of recordings, so
    > the box became logically unusable for the intended purpose (download
    > recordings for watching later on a different device).

    tte> I am saying the IETF is partially to blame because i think we also
    tte> proliferate the notion that certificates have to be renewed
    tte> periodically with maximum usual lifetimes of now i think one year ?
    tte> (was two years)

THIS IS NOT AN IETF POLICY.

    > Whether is a same browser or new tabs (white=internet,
    > black=internet-"anonymous", red="private-network") is IMHO secondary. I
    > do agree though that a browser for a lot of iot management cases could
    > be a lot smaller than an Internet browser, so it would fit itself
    > easier into embedded devices itself and be a lot more reliable and
    > predictable in its page rendering than all the horrenduously complex
    > options-galore W3C has produced for "The Internet TA realm".

I don't see what a use case for a browser in an IoT device.
A fridge with a panel? Sure, but it's probably big enough to an RPI or
Android equivalent OS inside, so it's not really constrained.

    > The iotops charter for example also does not talk about data management
    > for iot devices. This type of security operations would fall into that
    > type of charter point.

Our charter says:

} This includes (but is not limited to):
} - factory provisioning of devices
} - onboarding of devices
} - access control of devices to network resources
} - administrative control of devices
} - software/firmware upgrades
} - isolation/quarantine of devices
} - remediation of broken devices
} - end of life management of devices

I thought that it included backup/restore of configuration explicitely.
The reason that this is important is because is a broken device is replaced,
then you want to be able to transfer the configuration from the broken device
to the new device.
If the device abruptly (blue smokes gets out, being bricked, etc.) then in
order to have the old configuration requires that something back is up
regularly.

Ideally, configuration backup/restore should be independant of device type.
I don't know if YANG/RESTCONF has a generic way to get all things at this
point.  Perhaps it does. AFAIK, there is nothing like snmpwalk in RESTCONF,
but that's effectively what we need.

    >> We don't have Cu (CoAP support)in Firefox anymore, because one can't
    >> write new schemes as extensions due to security architecture changes.

    > Ok, i don't get that.

There was a plugin for firefox called "Cu"
https://github.com/mkovatsc/Copper

It implemented CoAP as a firefox extension.
My understanding is that Firefox changed things when they rewrote things in
Rust. Specifically, an extension can't register a new scheme (i.e. coaps), because
that opened the possibility that an extension would register and override "https".
Clearly, we need some other modular mechanism where we can get CoAP support back.
Copper was AWESOME.  I think that I had an old firefox install just to run
it,, but I don't know where I put that.

    > Somebody more tortured by the variety of iot relevant device to cloud
    > protocols should give an overview of all the stuff that will stay
    > relevant and would be within scope of IETF. I would suspect that
    > https/coap are reall just a smaller subset of what is relevant, so for

For industrial/data-acquisition IoT MQTT is where it's at.
There is a TLS-profile specification for it in ACE, I think.
Critical to using MQTT safely is per-device identity and TLS Client
Authentication, with private keys stored in a hardware TPM.

    >> The delegation voucher provides a history of ownership.  But, that
    >> isn't the device's certificate, it's the manufacturer's statement.  I
    >> don't see how we can use delegated-voucher to augment the LDevID,
    >> except by replacing it.

    > When we discussed BRSKI and change of ownership in the past years it
    > was always mitigated through the MASA and therefore vendor. I think
    > that is an important option. I would like to see the option of being
    > able to do this without any vendor/MASA involvement of course too.

    > I don't think it would be a problem to define suh a process, but i really
    > would prefer we would define those workflows abstract first so they're
    > not stuck in a specific protocol like BRSKI, but could more esily be
    > proliferated across various protocols faster.

Well, I'm not sure I understand what you are saying.
Perhaps you are saying that the Registrar concept needs to be abstracted and
applied to many protocols?

EAP-NOOB and DPP are both manufacturer-free onboarding processes.

EAP-NOOB has an AAA server, which is morally equivalent to a Registrar, but
it does not currently lead to an ownership transfer.
DPP is more nebulous, but the RIPE not-a-BCoP [cf: Good Place, "not a girl"]
tries to outline how it might be made more easily deployable.
  https://www.ripe.net/ripe/mail/archives/iot-wg/2020-October/000537.html

see section _Router-Led DPP Activity_

to make this work, we really need a standard API into the Home Router.
BFF USP/TR-369 has potential, but it's gonna take some running code to make
the profile a little more clear.

I'm completely uncertain if such a Home Router/Smartphone onboarding API
would be in scope or not for IOTOPS.  Is it Operational Practice?

    > aka: for the least difficult to implement "sell-on-ebay" option, you as
    > the outgoing owner could create a bearer token, and send that in email
    > to the ebay buyer and in parallel ship the product. Then the receiving
    > new owner could take ownership. But the vendor should not be able to
    > dis-own the product unless you as the owner explicitly create a
    > bearer-token.  --- just as an example.

We can implement this interaction with delegated-voucher "today"

---

From: "Amyas Phillips, Ambotec" <[email-masked]>
Date: Thu, 5 Nov 2020 12:55:38 +0000

Hi folks

Is there a definition of ownership you are using? If not I’d like to propose one because I've found ownership to be a not particularly useful concept in IoT, unless redefined. 

- Ownership as a fundamental legal concept of capitalist societies means having the rights to dispose of an asset how you please, including improving it and deriving benefits from it. 
- Assets historically were strictly physical. 
- When patents were invented it started being possible to own an object without having the right to physically copy it. 
- When copyright was extended to compiled software it started being possible to own an embedded device without having the right to copy its software.
- DMCA and EUCD and equivalents further removed the right to even modify the software.
- Most IoT devices are now sold with EULAs, constraining any remaining legal concept of ownership with contractual terms. 
- You can even find that a licence to use it is the only thing you get when you buy a device, legal title remaining with the vendor.

I’d like to suggest that we set aside legal title and say “ownership” for the purpose of this discussion means “logical control of a device”. Transfer of logical control is an important and delicate event in an IoT device’s lifecycle so this seems to fit within the aims of the charter, even if it isn’t mentioned explicitly.

I’d like to further suggest that logical control ultimately means the right to control what software is installed on a device. That is to say, ownership == logical control == the right to set and (if transfer of control is supported) replace the firmware update trust anchor. That is what ownership means. Every other form of control is delegated from that and is called something other than “ownership". 

That’s it. 

I’ve anticipated and tried to answer some possible objections. They run on a bit, sorry about that: 

1. What if an IC has an integrated secure element under logical control of a third party and it is impossible even for a person with legal title to seize control of that SE? 

That’s fine, just acknowledge the SE as a separate domain of control. Someone has physical title, possibly constrained by license terms. Someone has logical control of the SE. Someone has logical control of the ‘insecure’ computing environment. It would a similar situation in a device with a  main application processor and separate a wireless module with its own firmware. 

2. Wouldn’t this mean that any device whose firmware has to be signed by its OEM is still under the logical control of and “owned” by that OEM? 

Yes.

3. But that’s not who I mean when I talk about the owner! 

I get it, but this just means different and more specific terminology is required. You might mean the entity trusted by the device to issue application-layer commands (possibly including commands to set application-layer trust anchors).

4. What if an OEM retains firmware update rights but no direct connection, do they still have ultimate logical control? 

Yes.

5. What if the application can’t be updated? 

Logical control has been permanently delegated to whoever the device's application layer trusts. There always was control at the application layer, just in this case it is “ultimate” control. Assuming the application exposes logical interfaces and authenticates requests to them there are could be as many logical controllers / "owners" as there are trust anchors for authenticating them, but if there is one interface specifically for administering trust anchors then whoever controls that who is now the ultimate logical controller / “owner”. 

It has to be said that what can be controlled in this situation is much less than what someone with firmware update rights would be able to control. Also,  unless the new owner is able to validate the installed firmware against a build of the source code there’s no way they can know just what they are controlling. 

6. What if the device ships without trust anchors, who owns it then? 

It is in a first-to-claim state. That assumes that once “claimed” it can’t be claimed by anyone else without the current claimant’s authorisation. 

7. Who is the ultimate controller if there is an immutable initial bootloader with a trust anchor immutably set, and a stage two bootloader with another trust anchor, and an application? 

The immutable initial bootloader creates a firmware update right, i.e. an ownership right, which has been permanently claimed by whoever set its trust anchor. In most devices an immutable initial bootloader would allow updating a stage two bootloader, meaning the stage two bootloader’s TA can be changed. So whoever set the iniitial bootloaders' TA controls who gets to install the stage 2 bootloader, and whoever installs the stage 2 bootloader controls who gets to install the main application. 

The ultimate controller a.k.a. owner is whoever set the root TA. What they control has been determined by whoever designed and installed the initial bootloader and whoever designed and fabricated the IC running it, and perhaps whoever designed and manufactured the device running the IC. In this case the owner gets to decide who can install the second boot stage - probably themselves

8. Isn’t is possible to dream up IoT devices that don’t have logical controllers? 

I guess so - you could do without secure boot and expose unauthenticated interfaces, or you could make a device that is always claimable - but that doesn't invalidate the concept. 

9. What does transfer of ownership mean then?

Setting someone else’s TA in the initial bootloader. 

10. What if a hacker obtains arbitrary code execution?

They 0wn the device but they don’t own it - not unless they can make their control permanent across reboots. They have application layer logical control until a reboot. 

Thanks
Amyas

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2020 12:43:29 -0500

Amyas Phillips, Ambotec <[email-masked]> wrote:
    > Most IoT devices are
    > now sold with EULAs, constraining any remaining legal concept of
    > ownership with contractual terms.

    > You can even find that a licence
    > to use it is the only thing you get when you buy a device, legal title
    > remaining with the vendor.

Yes.
Many people have problems with this, but ideally, this state of things would be more explicit.
I think that, if explained clearly, that many entities would refuse to
"license" the device.

    > I’d like to suggest that we set aside legal title and say “ownership”
    > for the purpose of this discussion means “logical control of a
    > device”. Transfer of logical control is an important and delicate event
    > in an IoT device’s lifecycle so this seems to fit within the aims of
    > the charter, even if it isn’t mentioned explicitly.

    > I’d like to further suggest that logical control ultimately means the
    > right to control what software is installed on a device. That is to
    > say, ownership == logical control == the right to set and (if transfer
    > of control is supported) replace the firmware update trust anchor. That
    > is what ownership means. Every other form of control is delegated from
    > that and is called something other than “ownership".

This definition works for me.

    > 1. What if an IC has an integrated secure element under logical control
    > of a third party and it is impossible even for a person with legal
    > title to seize control of that SE?

    > That’s fine, just acknowledge the SE as a separate domain of
    > control. Someone has physical title, possibly constrained by license
    > terms. Someone has logical control of the SE. Someone has logical
    > control of the ‘insecure’ computing environment. It would a similar
    > situation in a device with a main application processor and separate a
    > wireless module with its own firmware.

    > 2. Wouldn’t this mean that any device whose firmware has to be signed
    > by its OEM is still under the logical control of and “owned” by that
    > OEM?

    > Yes.

Agreed.

    > I get it, but this just means different and more specific terminology
    > is required. You might mean the entity trusted by the device to issue
    > application-layer commands (possibly including commands to set
    > application-layer trust anchors).

Agreed.

    > It is in a first-to-claim state. That assumes that once “claimed” it
    > can’t be claimed by anyone else without the current claimant’s
    > authorisation.

Or, maybe it can't be updated, and it's first-malware-to-claim :-)

    > I guess so - you could do without secure boot and expose
    > unauthenticated interfaces, or you could make a device that is always
    > claimable - but that doesn't invalidate the concept.

Are you, in "always claimable", including the case that the device
manufacturer will delegate software signing to the legal physical owner?
Apparently, many enterprises demand the right to control what and when
updates are deployed, and thus this has become a thing in SUIT.

    > Setting someone else’s TA in the initial bootloader.

!yup.

    > They 0wn the device but they don’t own it - not unless they can make
    > their control permanent across reboots. They have application layer
    > logical control until a reboot.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2020 08:43:06 +1300

> This definition works for me.

It's attractive, but it leaves me with one concern. The concept of "ownership"
implies the concept of "theft". If ownership is defined in this new way,
what is the equivalent definition of theft? How do we know that the entity
with logical control really has the right to that control? How do we
know that control has been stolen?

I don't mean that this is a show-stopper, but it does mean that the new
definition chases its own tail to some extent.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2020 16:03:42 -0500

> know that control has been stolen?

It's a definite tussle between ownership and pwnership.

    > definition chases its own tail to some extent.

Legal code often is non-deterministic when executed on different "CPUs" :-)

---

From: William_J_G Overington <[email-masked]>
Date: Fri, 6 Nov 2020 08:01:08 +0000 (GMT)

Would it help if we defined new words, such as, for example, logconship 
(coined from parts of 'logical control ownership') and we define them 
precisely and permanently and publish the definitions and deposit them 
with dictionaries, legal deposit libraries such as The British Library 
and The Library of Congress and use the words precisely and exactly?
We could define several new words, how ever many we consider necessary, 
and never change the meanings once defined.
If a different meaning, no matter how slightly different, is needed then 
a new word would be defined and maybe some of the older words would 
drift out of use except in a historical context.
William Overington
Friday 6 November 2020

---

From: William_J_G Overington <[email-masked]>
Date: Fri, 6 Nov 2020 09:29:04 +0000 (GMT)

> We could define several new words, how ever many we consider 
> necessary, and never change the meanings once defined.
An End User Licence Agreement (EULA) can cause problems.
I have no experience of EULAs with Internet of Things devices, but my 
experiences with EULAs in relation to fonts may be of interest and have 
resonance with EULAs for Internet of Things devices.
One of the great design features of some computer operating systems, 
including Windows 10, is that most applications use fonts from a central 
fonts folder on the computer.
So when I am using the Serif PagePlus desktop publishing software to 
produce a PDF (Portable Document Format) document I can use any 
appropriately licenced font that is in the fonts folder of my home 
computer.
So I often use Goudita SF, a rather nice Venetian-style font bundled 
with PagePlus, a font based upon a typeface used by Nicolas Jenson in 
Venice in the 1470s.
There are lots of fonts out there and I would happily buy some of them, 
but the problem is often the EULAs. This is because I have a small 
webspace and I like to upload PDF documents that I produce with fonts 
embedded within them and make them free to read, no registration 
required, so I have no knowledge of how many copies, if any, are read by 
people accessing them on the web. The EULAs often want really high 
licence fees for known quantities of web accesses, and so I just cannot 
afford that and also I have no way of counting downloads and the net 
effect is that, no matter how good the design, I just do not buy or use 
the font because of the terms of the EULA.
So, I only use fonts supplied with the software or with other software 
from Serif, a few generously-offered open source fonts, and some fonts 
that I have produced myself using the High-Logic software programs 
FontCreator and Scanahand.
http://www.users.globalnet.co.uk/~ngo/
So maybe we need to have a new word, sanseulaship, from "sans (without) 
eula ownership". This would be pronounced with 'sans' as in sands 
without the 'd', eula pronounced 'yoo-la' and ship as in 'ownership, 
thus four syllables, san(d)s - yoo - la - ship.
Example sentences:
This company will only purchase sanseulaship devices.
The sanseulaship policy of the manufacturer has increased the sales of 
its devices and their widespread deployment.
A word that I coined, telesoftware, is now in the Oxford English 
Dictionary. The coining of new words to encapsulate new meanings is 
entirely acceptable and part of the way that the English language 
evolves and develops over time.
If the word sanseulaship is to be useful and become used we need a 
precise definition to be produced and agreed by this group, then 
published and sent to some dictionaries and to some legal deposit 
libraries.
.
William Overington
Friday 6 November 2020