Focusing on the generalization of concepts, functionality, and overall processes involved in the creation of a secure 'network of trusted data' , the IDS-RAM resides at a higher abstraction level than common architecture models of concrete software solutions do. The document provides an overview and dedicated architecture specifications.
Creative Commons Attribution 4.0 International
38
stars
27
forks
source link
Securing Interaction between IDS Components: chapter does not consider changed Identity and Trust Management #212
Is the mapping on private and public key still correct? My understanding was, that the Keys (such as C_UID) are not mapped on the key pair.
The mapping of identities is performed in this chapter on organizational level, while the Identities can also be mapped on participant (person within an organization) has been introduced.
The overall identity key ("A private key called Identity Key") should be the "Component Identity Key", doesnt it? Always differentiating between device and component identity is beneficial for the reader.
The device identity certificate mentioned here, seems to (more or less) match the platform identifier.
While reading through latest changes it seems, that the chapter 4.1.5 Securing Interaction between IDS components has not yet been updated according to 4.1.2 Identity and Trust Management. I had following findings: