Replies: 1 comment 1 reply
-
|
Yes. But remember that the admissions certificate is not an access control decision, its a trust decision. Even with two way secure communications, one party may limit access to some resources to another trusted party. That's why we expose the measurement on the secure channel. You can implement an Access control list to provide very efficient, very granular access control no matter who trusts who. I had trouble imagining a situation where bot harties would not want to make some trust judgement about the other parties code. Having said all that "one way trust" would just require "server only" auth under TLS (which is quite common) rather than mutual bilateral trust. |
Beta Was this translation helpful? Give feedback.
-
I got it. Each application can utilize other parties' measurements for access control, under the assumption that they know each others' measurement in advance. (this assumption is likely true in most cases) PS: I think it would be nice to see an example, as one of your examples, that can guide users how to implement an additional access control on top of your foundational mechanism. Maybe, would it be a good feature to add in "helper"? (I mean not only "one-way" but also controlling "who trusts who", e.g., A<->B allowed but B<->C not allowed) |
Beta Was this translation helpful? Give feedback.
-
From my personal experience of Certifier framework, parties that want to establish a secure channel would get an admission cert from certifier_service once they're authenticated.
Then, they can start a two-way secure communication with each other, which means
My question is, is there a way, in the certifier framework, to make it one-way secure communication for a more fine-grained security policy?
e.g.,
More generally speaking, you can view this as a kind of information control flow enforcement.
Beta Was this translation helpful? Give feedback.
All reactions