I include Kent's email at the bottom, in complete form, but I'll reply inline
to a copy up here.  This is fundamentally about the format and requirements
for the ownership voucher.

    > This is the ownership-voucher idea, but with the following distinctions:
    > 1) uses X.509 certs
    > - this is compelling, as using an existing standard with lots of
    > available tooling sounds like a win.

Yes, when I thought hard about the problem, I realized that while they
were not attestations as to identity (which a certificate usually is), that
they were attestations as to ownership, and then I realized that it was
identical to the SIDR work that binds ISPs to BGP4-ASN and IP address ranges.

So, in: https://datatracker.ietf.org/doc/draft-richardson-anima-idevid-cert/
I blantantly stole from RFC3779, even forgetting to delete some of the
terminology..



    > 2) uses a delegation model
    > - that is, each owner generates a sub-cert when selling some of their
    > stock.  This I have mixed feelings about. On one hand it seems
    > natural/intuitive, and yet it does also  mean that the
    > delegates have to 1) setup PKI and 2) be trustworthy.

I agree that it's a serious challenge to get things setup!

1) My comments are that we can skip many layers in the hierarchy depending upon
   the value and cluefulness of the layers.  A MASA, provided by the
   end-customer with a PSK from a QR code, can retrieve the end-certificate
   from the vendor directly.  It's basically a form of PSK authenticated EST.

2) For higher value items (like routers from big manufacturers), I suspect
   that this system would actually be simpler than the nonsense I have gone
   through trying to obtain firmware... At the least, it would filter out
   clueless intermediaries that simply cost everyone time and money.


    > 3) this solution seems geared for consumer-oriented gear, stuff one
    > might get a Best Buy.

Well, is this because my example involved Road Runners and Coyotes, and
Cadabra was the original name for Amazon, I learnt from Wikipedia.

I don't think that it's a failure of such a system if it can be made to work
at the scale of retail.  I'd say it's a major feature.  The retail scale
is both massive (Best Buy moves a lot of devices), and miniscule (people only
buy one or two devices/year at present).

At the personal level, the question becomes: is there actually *any*
infrastructure we can depend upon?  At the retail level, the question is the
opposite: if there are any human interactions required, it's a fail.


    > 1) only the manufacturer can sign the vouchers
    > - no one else needs to setup signing infrastructure
    > - manufacturer can ensure a voucher is only created once per device
    > - manufacturer MAY be able to reassigned a voucher, but this might
    > entail needing to maintain something like a voucher-revocation-list
    > (VRL?), which would create further dependencies on clocks (ugh!)

One model, where you stop here: is a bearer token.
I think that this model is entirely doable, and makes sense for devices
of a certain price/point.   But, it might be that this has significant
externalities which society would not want, such as DDoS if the devices
can be trojaned and then new vouchers affixed.

    > 2) at some point, the device is sold to an entity that wants to take
    > ownership
    > of the device.
    > - this entity MUST have (within my soln.) previously obtained an owner
    > certificate from the manufacturer.

    > - this entity submits a "voucher signing request" (VSR?), signed by its
    > private
    > key, to the manufacturer, along with its previously-signed owner
    > certificate,

So, this is my model with a QR code.

    > - Instead of submitting its owner certificate, the entity might instead
    > log into
    > the interface, from which the manufacturer could lookup the same info as
    > in the owner certificate...







Kent Watsen <[email protected]> wrote:
    > Here’s the URL to the MCR’s email:

    > 
https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

    > This is the ownership-voucher idea, but with the following distinctions:
    > 1) uses X.509 certs
    > - this is compelling, as using an existing standard with lots of
    > available tooling sounds like a win.

    > 2) uses a delegation model

    > - that is, each owner generates a sub-cert when selling some of their 
stock.
    > This I have mixed

    > feelings about. On one hand it seems natural/intuitive, and yet it does 
also
    > mean that the

    > delegates have to 1) setup PKI and 2) be trustworthy.

    > 3) this solution seems geared for consumer-oriented gear, stuff one might 
get
    > a Best Buy.

    > I haven’t put much thought to a consumer-oriented solution, but maybe
    > something like this would work:

    > 1) only the manufacturer can sign the vouchers

    > - no one else needs to setup signing infrastructure

    > - manufacturer can ensure a voucher is only created once per device

    > - manufacturer MAY be able to reassigned a voucher, but this might

    > entail needing to maintain something like a voucher-revocation-list

    > (VRL?), which would create further dependencies on clocks (ugh!)

    > 2) at some point, the device is sold to an entity that wants to take
    > ownership

    > of the device.

    > - this entity MUST have (within my soln.) previously obtained an owner

    > certificate from the manufacturer.

    > - this entity submits a “voucher signing request” (VSR?), signed by its
    > private

    > key, to the manufacturer, along with its previously-signed owner 
certificate,

    > - Instead of submitting its owner certificate, the entity might instead 
log
    > into

    > the interface, from which the manufacturer could lookup the same info as

    > in the owner certificate...

    > - The VSR is essentially just a list of device unique-ids and, for each, 
some

    > “proof of ownership”.

    > - Proof of ownership could take on different flavors, but when ownership

    > can only be taken once, a simple code inside the packaging might suffice.

    > 3) the above assumes physical possession of the device at the time the 
VSR is

    > submitted, but that is not always desirable. For instance, the owner may

    > have instead placed an order for devices to be dropped-shipped to some

    > specific locations.

    > - In this case, the owner would like to get the vouchers as soon as the
    > devices

    > are shipped, and before the boxes are opened, so that they can stage the

    > network in preparation for the devices being powered on.

    > - In my view, this gets into a high-touch scenario where it is appropriate
    > for

    > the manufacturer to proactively issue the vouchers. That is, instead of

    > receiving a VSR, the manufacturer receives an *order*, which it can again

    > correlate to the appropriate owner certificate.

    > - this is in essence what is documented in the current zerotouch draft.

    > What do you think? - especially regarding (2) above, as that is the new
    > part...

    > Kent




--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to