To Ron, Ben, et. al.:
The primary purpose of having a third party sign a certificate is to provide assurance that an organization (in code signing) or server (in server certs) is what it claims to be. In this case, a trusted third party provides the assurance through its registration process and Certificate Policy (CP) and Certificate Practice Statement (CPS) that the root CA imposes on those organizations. However, in the case of the trustworthiness of the log entries, there are two issues: First, the validity of the time stamp. I always advise my clients to have a Corporate Policy that establishes standard time throughout the organization. I also advise that the time utilized be traceable to an internationally recognized time source such as those provided by NIST. I will gladly send my generic Time Standard Policy V2.0 and associated Time Standard Procedure V1.0 to those that write me directly. If enough people request it, I'll send it as an attachment to an email to the mailing list. I just converted the documents to PDF files for this purpose. Second, the integrity of the information that is being logged. By time stamping and signing the information as each log record (or audit trail) is produced, a mechanism has been put in place to demonstrate the integrity of the information. I always advise my clients that quality assurance testing plays a major role in the security process. Security metrics should be developed and quality assurance tests should be devised that demonstrate that a system prior to its deployment and also periodically during its deployment is performing as expected. Tests can easily be designed to demonstrate that a specific event does indeed produce the expected log record/audit trail and that each entry is properly time stamped and signed by the system. To support the digital signing process, an organization can establish its own root CA provided it also prepares appropriate CP/CPS documents (these are legal documents and should be developed with the assistance of corporate counsel) plus establishes the necessary formal security policies, practices, and procedures (SPPPs) regarding (cryptographic) key management (KM). Again, the SPPPs should contain information pertaining to the security metrics by which compliance can be validated. As before, quality assurance tests should be devised that can produce measurable feedback that KM is being complied with both prior to production role out and then periodically afterwards. An organization that has formally documented SPPPs and can repeatedly demonstrate compliance to them, I believe has provided evidence of the trustworthiness of those log record/audit trail entries. In such a situation, I do not believe that a third party CA is necessary to ensure trustworthiness. Respectfully; Marc Mandel -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
