Roman Danyliw via Datatracker <[email protected]> wrote: > (4) Thank you for documenting “manufacturer control issues” in Sections > 10.3 and 10.4. It helpfully lays justifies the current design > approach. I strongly concur with the premise that “facilitate[ing] a > few new operat[i]onal modes without making any changes to the BRSKI > protocol” is exactly what is needed.
> My concern is that even with the current applicability statement in
> Section 9, the current text appears to have only standardized the first
> part of the lifecycle that BRSKI equipment might see -- equipment on
> first sale as long as the manufacturer supports it or stays in
> business. The text doesn’t appear to cover the practical aspects of
> the proposed mitigations in Section 10.5 or the situations described in
> Section 10.3/10.4 – various situations possible in the full lifecycle
> usage of a BRSKI device and needed support the “additional operational
> modes”. Specifically:
> ** There appears to be little discussion on how
> owners/manufacturers/vendors can facilitate second sale/used equipment
> beyond narrative words (in Section 10.3 and 10.4)
> ** There is appears to be little discussion on how to practically
> implement a MASA (i.e., the offline use case). For example, (Per
> Section 10.5) “A manufacturer could provide a mechanism to manage the
> trust anchors and built-in certificates (IDevID) as an extension. This
> is a substantial amount of work, and may be an area for future
> standardization work”. Without the ability to change anchors on the
> device the additional operational modes such as offline mode seems
> challenging.
Our goal here has been to provided bootstrapping... the beginning of the
lifecycle. It would be great to be able to provide full lifecycle
specification.
There are quite a number of non-technical issues (i.e. layer 8 and 9)
involved in supporting a second sale process. Updating the trust anchors
that are used to verify the voucher is, I think, a pretty big deal, and
I just don't see that we can deal with this in a general way for a variety of
product types. Some vendors would see this as meaning that the TPM has
to be opened up. Some operators would be concerned that if this was
possible, that they would no longer be able to be certain that a secure
boot process would still be secure. I would be happy if this work was
chartered a "RATS 2.0", or became part of NETMOD. I don't see how we
can do justice in this document.
As for operational notions as to how to operator a MASA, and as you say, one
that supports off-line vouchers, I agree that we are not that helpful.
Note that off-line vouchers are ones without nonces and without expiry dates,
transfered to the Registrar by store-and-forward (USB key, scan from
QR code on invoice, etc.). They are still signed by the primary
manufacturer, and still bind to the primary owner. They are not bearer
tokens, and they do not require changes to the trust anchors, and they do not
facilitate second sale.
Perhaps there is something I can change in that section to clarify this point.
To use an HTTP 0.9 analogy, it's like asking the http (1.0) WG to comment on
how whether Model-View-Controller vs Presentation-Abstraction-Control is
the right way to build social media sites.
Having said that, I am pretty sure that we need to write an Operational
Considerations document for both MASA and Registrar. I suspect that the
first draft will mostly be a list of things not to do. ("Doctor it hurts when
I move my harm like this...")
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
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
