Brian E Carpenter <[email protected]> wrote: >> problem 1. Anoop> The major problem with the procedure is that the registrar doesn’t Anoop> verify the manufacturer. >> >> To translate, the JRC has no obvious way to verify that the "MI" key belongs >> to the manufacturer that they care about. >> >> You actually hit the major reason this is not a problem when you assume: >> > assuming the registrar can’t know all the manufacturers exhaustively >> >> We assume that in a managed network that the JRC *can* know all the >> legitimate manufacturers. The keys can come from sales channel integration >> (via digital "packing slips" perhaps), can be manually loaded by humans, be >> scanned from QR codes on the box, etc. We believe that this is out of scope.
> Yes, but please ensure that the draft states this assumption and states
> that how it is achieved is out of scope.
> Also note the air-gap case described in section 6.3 bullet 3. That's
listed
> as a security reduction, but if your threat model considers rogue MASAs
> to be a real risk, pre-loading vouchers and then totally disconnecting
from
> the Internet might even be considered a security improvement.
I agree that there should be another Security Considerations section.
Should we also say something in the Introduction?
https://github.com/anima-wg/anima-bootstrap/issues/43
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
