Toerless Eckert <[email protected]> wrote:
    > This goes back to your observation from the content-type discussion:

    > "Data items not mentioned SHOULD be ignored."

Postel Principal:  be liberal in what you accept.

I can't stop people putting extra stuff in their objects, but we can tell
receivers what to do when they see that stuff.

In this case, we have reasons why a library might include x5bag support (for
the voucher).   My Voucher-Request class is a subclass of Voucher, for instance.
I can easily goof here and include x5bag on the voucher-request.

    > BUT: Vendors (running MASA) could be very curious. Lightbulbs enrolling
    > may want to encode in some opague data of the VR (such as the cert)
    > information spoofed about the environment, such as the wifi BSSIDs
    > it sees, aka: Mac Addresses of WiFi APs. This is what google for example
    > uses to guess where you are on the planet.

Uhm. Sure.

    > Given how some ANIMA observers are concerned about MASA/Vendors,
    > i think we should do our best to avoid unnecessary side channel
    > opportunities.

But, there are lots of other places, and I'm working on a document, for
instance, on carrying RATS EAT Evidence through the VR.

    > So: Why would we not want to specify that pledge MUST NOT include
    > into the voucher elements not explicitly mentioned in the document ?

Because it's not enforceable, and it results in failures to interoperate when
we introduce new things.

If we say that anything new causes the VR to be dropped, then we can never
add new things, because it causes interoperation issues if the pledge
starts adding them before the Registrar is ready.

--
]               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]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

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

Reply via email to