Elaborate on reporting steps for auditor attestation of Trademark Compliance #572
Conversation
Updated the auditing process document to include links to relevant documents and clarified compliance requirements for integrators.
calebofearth
requested review from
Bryankel,
andreslagarcavilla,
jhprabhu and
nvpachou
as code owners
calebofearth
requested review from
JohnTraverAmd,
syncsrc-nv and
varuns-nvidia
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The auditing process will be captured in a “Process” document that can be used by vendors to request permission to use the Caliptra trademark. Additionally, a “Checklist” document will be provided, which can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. | ||
|
|
||
| The main objective of the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) is to ensure the secure integration of Caliptra in another device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: | ||
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The [auditing process document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraTrademarkAuditProcess.md) can be used by vendors to request permission to use the Caliptra trademark. Additionally, the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. To demonstrate compliance with the Caliptra Integration Requirements, integrators must provide necessary collateral to security auditors for each integration requirement. This includes documentation such as: integrated RTL, synthesized netlist reports, GLS FEV reports, SoC boot diagrams, etc. Additionally, some integration requirements may not be verified through tool reports or through code analysis. For such requirements, integrators must provide documentation summarizing plans and procedures (for example, generation of an obfuscation key in compliance with NIST). Security Auditors must review the materials and prepare a Statement of Conformance that attests to integrator compliance with all requirements. The main objective of this checklist procedure is to ensure the secure integration of Caliptra into a device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: |
There was a problem hiding this comment.
[auditing process document] link looks to be pointing to this file? I don't think that subsequent sections of this document adequately define what a trademark request submission would look like in practice (the mentioned "Statement of Conformance" is not defined anywhere in the existing version).
Recommend removing "security" from "Security Auditors". Also, the whole last sentence (The main objective of this checklist procedure ...) and subsequent bullet points should probably also be dropped. This document isn't the place for commentary on why the requirements exist.
There was a problem hiding this comment.
"This includes documentation such as: integrated RTL, synthesized netlist reports, GLS FEV reports, SoC boot diagrams, etc."
This is now clearly a technical security assessment that involves code review rather than a paperwork exercise. This may have always been the intent, but previously it was open to interpretation. Is that a correct assessment of this new paragraph?
(in which case I think removing "security" from "security auditor" is not correct)
There was a problem hiding this comment.
Would that mean non-security-impacting trademark requirements don't need to be audited? These docs define the audit scope and requirement, adding qualifiers seems unnecessary and potentially counterproductive.
There was a problem hiding this comment.
@syncsrc-nv agreed on many of your formatting comments. Having a self-link in the document can be cleaned up. We'd first like to settle on the change in direction that this document proposes, then we'll come back and clean up formatting. I'll leave this conversation open to track the todo there. @ericeilertson is going to take point on finalizing this effort.
There was a problem hiding this comment.
This is now clearly a technical security assessment that involves code review rather than a paperwork exercise. This may have always been the intent, but previously it was open to interpretation. Is that a correct assessment of this new paragraph?
What we're proposing in this PR is a clarification to the process. We've always required an audit, but the goal of this PR is to make it more clear what that entails. @ericeilertson any additional comments?
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The auditing process will be captured in a “Process” document that can be used by vendors to request permission to use the Caliptra trademark. Additionally, a “Checklist” document will be provided, which can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. | ||
|
|
||
| The main objective of the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) is to ensure the secure integration of Caliptra in another device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: | ||
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The [auditing process document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraTrademarkAuditProcess.md) can be used by vendors to request permission to use the Caliptra trademark. Additionally, the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. To demonstrate compliance with the Caliptra Integration Requirements, integrators must provide necessary collateral to security auditors for each integration requirement. This includes documentation such as: integrated RTL, synthesized netlist reports, GLS FEV reports, SoC boot diagrams, etc. Additionally, some integration requirements may not be verified through tool reports or through code analysis. For such requirements, integrators must provide documentation summarizing plans and procedures (for example, generation of an obfuscation key in compliance with NIST). Security Auditors must review the materials and prepare a Statement of Conformance that attests to integrator compliance with all requirements. The main objective of this checklist procedure is to ensure the secure integration of Caliptra into a device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: |
There was a problem hiding this comment.
Additionally, some integration requirements may not be verified through tool reports or through code analysis.
Do you mean that it may not be possible to verify through tool reports/code analysis (in which case, fallback ti summary documentation)? Or do you mean that for certain requirements, it is not allowed to use tool reports/code analysis?
I assume you mean the former, in which case I think clarifying that language a bit would be helpful.
There was a problem hiding this comment.
"Additionally, some integration requirements are not easily verified through tool reports or through code analysis."
I think this sounds better
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The auditing process will be captured in a “Process” document that can be used by vendors to request permission to use the Caliptra trademark. Additionally, a “Checklist” document will be provided, which can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. | ||
|
|
||
| The main objective of the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) is to ensure the secure integration of Caliptra in another device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: | ||
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The [auditing process document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraTrademarkAuditProcess.md) can be used by vendors to request permission to use the Caliptra trademark. Additionally, the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. To demonstrate compliance with the Caliptra Integration Requirements, integrators must provide necessary collateral to security auditors for each integration requirement. This includes documentation such as: integrated RTL, synthesized netlist reports, GLS FEV reports, SoC boot diagrams, etc. Additionally, some integration requirements may not be verified through tool reports or through code analysis. For such requirements, integrators must provide documentation summarizing plans and procedures (for example, generation of an obfuscation key in compliance with NIST). Security Auditors must review the materials and prepare a Statement of Conformance that attests to integrator compliance with all requirements. The main objective of this checklist procedure is to ensure the secure integration of Caliptra into a device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: |
There was a problem hiding this comment.
Maybe change "This includes documentation such as" -> "This may include documentation such as" to clarify that not all of these things are required for every single requirement. Basically it's a judgement call by the auditor.
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The auditing process will be captured in a “Process” document that can be used by vendors to request permission to use the Caliptra trademark. Additionally, a “Checklist” document will be provided, which can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. | ||
|
|
||
| The main objective of the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) is to ensure the secure integration of Caliptra in another device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: | ||
| This document defines an auditing process to be used by vendors to determine if the vendor’s products meet the Caliptra trademark requirements. The [auditing process document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraTrademarkAuditProcess.md) can be used by vendors to request permission to use the Caliptra trademark. Additionally, the [Checklist and evaluation methodology document](https://github.com/chipsalliance/Caliptra/blob/main/CaliptraChecklistAndEvaluationMethodology.md) can be used by vendors to determine if the vendor is complying with the Caliptra Integration Specification. To demonstrate compliance with the Caliptra Integration Requirements, integrators must provide necessary collateral to security auditors for each integration requirement. This includes documentation such as: integrated RTL, synthesized netlist reports, GLS FEV reports, SoC boot diagrams, etc. Additionally, some integration requirements may not be verified through tool reports or through code analysis. For such requirements, integrators must provide documentation summarizing plans and procedures (for example, generation of an obfuscation key in compliance with NIST). Security Auditors must review the materials and prepare a Statement of Conformance that attests to integrator compliance with all requirements. The main objective of this checklist procedure is to ensure the secure integration of Caliptra into a device, to ensure that Caliptra can leverage its main security functionality (security services) and remain secure. The main security functionality of Caliptra as a silicon RoT, when integrated, is to: |
There was a problem hiding this comment.
synthesized netlist reports, GLS FEV reports
Would it make sense to add this to the checklist instead? I am concerned that if we leave it here it is going to raise more questions than answers.
Explained how compliance with the Caliptra integration requirements may be demonstrated and attested during Trademark review process.