Eliot, thanks for this document. If nothing else, it means that we BRSKI authors can deal with some review comments by pointing to "future work" :-)
(A)"request-voucher-with-possession" <-- what about intent to traffic? :-) (for those that don't get the joke: https://criminal.findlaw.com/criminal-charges/possession-with-the-intent-to-distribute.html ) if leaf out-of-band-claim to be set by the PLEDGE? I think it is set by the Registar? The document sadly ends too soon... You say it is trying to do a few things. 1) deal with middle value pledge, (and low-value pledges in very congested places) where an out-of-band supply-chain integration is unavailable, and the MASA has a any-registar policy for the device. 2) provide a ship-and-forget mechanism. It seems that the cryptographic POP mechanism is an ends to accomplish a means, rather than a core goal of the protocol. The Pledge already can sign it's voucher-request, and since it includes the Registrar's key when it does a proximity assertion, it's pretty good proof of possession for the *Registrar*, but it might provide inadequate assurance to the MASA of it's freshness. If the MASA could provide a nonce for the pledge to sign (requiring another round trip, and even more online assurance), that would provide even more proof. Given that you pushed this out before today's cutoff, I am not upset that there is so few details. I am suspecting that in your thinking that you created the three objects, and realized that could accomplish "ship-and-forget" using a combination of them? I also wonder if cryptographic-POP is being confused with "proof of ownership", which I think is what you really want to accomplish. If one assumes some machine readable (QR) code that comes with the product, then there are a few things one can do to differently. One of the things that I have thought a lot about is that one uses the printed code in the Registrar to establish a relationship with the MASA. That is, one creates the supply-chain-integration by using the QR code with some zero-knowledge proof (I think that PAKE is the latest one) to establish that one is the legitimate Registrar for the product. One can do this as *any time* (some mumble about the lifetime of the CA of the Registrar's key), and the product will be enrolled correctly at any future time. About my joke (A) above, I think that ship-and-forget is an interesting goal, and in particular, if also may enable desireable "traffic"ing. That is, if the manufacturer can transfer the product to my ownership without any online interaction, then presumably, I can also *resell* the device to you using the same lack-of-interaction? ==== > In addition, some manufacturers may prefer not to require the > existence of a MASA. In these circumstances proof of possession to > the device is required. I would prefer that we split this into a different draft. I am very concerned that ship-and-forget is not a desireable property in the IoT space. It essentially means that the manufacturer has no further interest in providing any kind of updates for the device. I have serious cybersecurity concerns about such devices being out there (sitting unpatched and untracked in a warehouse somewhere), as well as significant environmental concerns about devices designed to die like this. I am trying to think of devices where this makes sense. I come up with a few things: single-use medical devices (like bandages, syringes, etc.), prophylactics and other single-use sex toys, things you eat, and some variety of devices that might be called "spy craft". In each case, I'm having difficulty knowing what the "smart" aspect of the product is, other than simply tracking it's existence and current stocking location. A smart package containing a dumb device is a good idea, but it seems like something that would be better recycled, and in any case, it's not ship-and-forget for the packaging. So this is why I think that splitting ship-and-forget mechanism into another document would let us treat it better. In particular, I want to know who is going to deploy using such mechanisms, and if they are at the table now. I guess I shall add a slide to my ANIMA BRSKI stack about this in an attempt to get feedback. I suspect that there is a category of devices that some think of being ship-and-forget which might actually be ship-to-holding-company. Holding company leases to end user for period of time. End user identity is never communicated back, and might be very much pseudonymous. I'm thinking about car-rentals, hotel rooms (full of devices), ... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
