should the trusted properties be grouped into a subobject (i.e. trusted!pid, trusted!uid, etc)?
I think that the answer is yes for the following reasons
1. there may be multiple PID objects. For examplthe syslogtag includes a PID. It's useful to have both what the application claims and what the system claims and be able to compare the two.
2. when relaying from one machine to another, the trusted properties need to be handled specially depending on the degree of trust that the transport protocol provides (and that the sysadmin places on that trust)
3. there needs to be some protection to prevent people from generating logs that have the trusted properties in them. This is easier if these are in one object and you can protect that object than if they are a bunch of individual properties that have to be protected seperately.
4. If there is a trusted subobject, it's easier to extend. For example, when logs are being relayed from one system to another, the recieving system can add items into the trusted subobject to provide information about the connection. For example, it could add certificate information or the remote IP address of the sending machine.
I would define this trusted object as something like:
Fields in the Trusted object should be generated by the software recieving the log messages and MUST not be able to be affected by anything that the application generating the log puts into the log message.
Applications recieving relayed log messages SHOULD update the Trusted object to identify if the data should still be trusted.
Applications recieving relayed log messages MAY update the Trusted object with additional information indicating why the fields should still be trusted.
Thoughts?
David Lang