Difference between revisions of "Technical Team/Proposals/2012-06-06/Detached Signed SPDX Files"

<p>&nbsp;</p><h2>Status</h2><p><strong>Draft</strong></p><h2>Issue</h2><p>Currently there is no way to be sure that an SPDX file has not been modified by a third party after it was produced. See also,&nbsp;<a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to state that</p><ol><li><strong>Signing Convention:&nbsp;</strong>SPDX producers&nbsp;<strong>may&nbsp;</strong>&nbsp;cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440.&nbsp;This format does not modify the original SPDX, but rather creates a separate &lt;filename&gt;.sig or &lt;filename&gt;.sign file containing a signature for the original file. &nbsp;</li><li><strong>Signature File Naming Convention:&nbsp;</strong>The signature filename should be either &lt;filename&gt;.sig or &lt;filename&gt;.sign and be in the same directory as the SPDX file.</li><li>Renames of an SPDX file from &lt;filename1&gt; to &lt;filename2&gt; should also rename any &lt;filename1&gt;.sig or &lt;filename1&gt;.sign files to &lt;filename2&gt;.sig or &lt;filename2&gt;.sign respectively. &nbsp;</li><li>SPDX consumers&nbsp;<strong>may</strong>&nbsp;accept or ignore SPDX signature files.&nbsp;</li><li>SPDX producers would have the option of signing SPDX files but would&nbsp;<strong>not</strong>&nbsp;be required to do so. &nbsp;</li></ol><h3>Example</h3><h5>SPDX file</h5><pre><code> SPDXVersion: SPDX-1.0 DataLicense: PDDL-1.0 Creator: Person: Ed Warnicke </code></pre><h5>Signed SPDX file</h5><pre><code> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo vuAAn2gLkGsGOntkUTERnISOyOoBJxlT =JxE7 -----END PGP SIGNATURE----- </code></pre><h5>Command sign an SPDX file</h5><pre><code> $ gpg --armor --output example.spdx.sign --detach-sig example.spdx</code></pre><h2>Advantages</h2><p>Detaching the signature in the SPDX file has several advantages.</p><ol><li>It allows underlying tools that are used to process the formats into which SPDX is normally encoded (RDF tools, Tag Tools, XML Tools, etc) to continue to function normally.&nbsp;</li><li>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues. &nbsp;A tool maker who *just* wants to focus on processing SPDX data does not need to worry about MIME wrappers.</li><li>It follows the convention already being followed by kernel.org, mavencentral, the apache foundation, and most packagers.</li></ol><h2>Disadvantages</h2><p>Detaching the signature in the SPDX file could lead to</p><ol><li>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li>Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files.</li></ol><div><h2>Responses to Disadvantages</h2><ol><li>SPDX signature files can be passed along with SPDX data files by simple archiving in a common archive format like .zip, providing all of the benefits of inline signatures, while retaining the advantages of detached signatures.</li><li>The SPDX signature file naming and placement conventions in the proposal eliminate concerns about correlation.</li></ol></div><h2>Compatibility</h2><p>This proposal will produce files that <strong>are</strong> backwards compatible. Specifically a signed filed will be readable by SPDX-1.0 compliant consumers and any tool capable of reading it's underlying encoding format (RDF, XML, Tag). By making the issue of signing orthogonal, we maintain separation of concerns.</p><p>&nbsp;</p>