https://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&feed=atom&action=historyTechnical Team/Proposals/2012-01-17/Signed SPDX data - Revision history2024-03-28T09:17:49ZRevision history for this page on the wikiMediaWiki 1.23.13https://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1344&oldid=prevMartinMichlmayr: Convert to MediaWiki syntax2013-03-07T11:27:08Z<p>Convert to MediaWiki syntax</p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 11:27, 7 March 2013</td>
</tr><tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline"><h2></del>Status<del class="diffchange diffchange-inline"></h2><p><strong>Rejected</strong></p><h2></del>Issue<del class="diffchange diffchange-inline"></h2><p></del>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, <del class="diffchange diffchange-inline"><a href="</del>https://bugs.linuxfoundation.org/show_bug.cgi?id=980<del class="diffchange diffchange-inline">"></del>issue 980<del class="diffchange diffchange-inline"></a></del>.<del class="diffchange diffchange-inline"></p><h2></del>Proposal<del class="diffchange diffchange-inline"></h2><p></del>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <del class="diffchange diffchange-inline"><strong></del>not<del class="diffchange diffchange-inline"></strong> </del>be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <del class="diffchange diffchange-inline"><strong></del>not<del class="diffchange diffchange-inline"></strong> </del>be required to do so.<del class="diffchange diffchange-inline"></p><p></del>The S/MIME and x.509 certificates are widely deployed, well tested and standardized way to provide cryptographically secure message authentication and non-repudiation. The relevant documents are <del class="diffchange diffchange-inline"><a href="</del>http://tools.ietf.org/html/rfc3851<del class="diffchange diffchange-inline">"></del>RFC 3851<del class="diffchange diffchange-inline"></a> </del>and <del class="diffchange diffchange-inline"><a href="</del>http://tools.ietf.org/html/rfc3850<del class="diffchange diffchange-inline">"></del>RFC 3850<del class="diffchange diffchange-inline"></a></del>. The resulting files are easy to process using widely available tooling both programmatically and manually.<del class="diffchange diffchange-inline"></p><p></del>The SPDX data would be embedded in the file in clear text which means specific tooling is only needed when signature authentication is required. Combining the signature and the SPDX data will simplify tooling to authenticate files and reduce the chances that signatures will be accedentally removed from an SPDX dataset.<del class="diffchange diffchange-inline"></p><h2></del>Compatibility<del class="diffchange diffchange-inline"></h2><p></del>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.<del class="diffchange diffchange-inline"></p></del></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>Status<ins class="diffchange diffchange-inline">: rejected</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">==</ins>Issue<ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>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, <ins class="diffchange diffchange-inline">[</ins>https://bugs.linuxfoundation.org/show_bug.cgi?id=980 issue 980<ins class="diffchange diffchange-inline">]</ins>.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">==</ins>Proposal<ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <ins class="diffchange diffchange-inline">'''</ins>not<ins class="diffchange diffchange-inline">''' </ins>be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <ins class="diffchange diffchange-inline">'''</ins>not<ins class="diffchange diffchange-inline">''' </ins>be required to do so.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>The S/MIME and x.509 certificates are widely deployed, well tested and standardized way to provide cryptographically secure message authentication and non-repudiation. The relevant documents are <ins class="diffchange diffchange-inline">[</ins>http://tools.ietf.org/html/rfc3851 RFC 3851<ins class="diffchange diffchange-inline">] </ins>and <ins class="diffchange diffchange-inline">[</ins>http://tools.ietf.org/html/rfc3850 RFC 3850<ins class="diffchange diffchange-inline">]</ins>. The resulting files are easy to process using widely available tooling both programmatically and manually.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>The SPDX data would be embedded in the file in clear text which means specific tooling is only needed when signature authentication is required. Combining the signature and the SPDX data will simplify tooling to authenticate files and reduce the chances that signatures will be accedentally removed from an SPDX dataset.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">==</ins>Compatibility<ins class="diffchange diffchange-inline">==</ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div> </div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">[[Category:Technical]]</ins></div></td></tr>
</table>MartinMichlmayrhttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1343&oldid=prevPezra at 03:58, 6 March 20122012-03-06T03:58:44Z<p></p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 03:58, 6 March 2012</td>
</tr><tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><h2>Status</h2><p><strong><del class="diffchange diffchange-inline">Draft</del></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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><p>The S/MIME and x.509 certificates are widely deployed, well tested and standardized way to provide cryptographically secure message authentication and non-repudiation. The relevant documents are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually.</p><p>The SPDX data would be embedded in the file in clear text which means specific tooling is only needed when signature authentication is required. Combining the signature and the SPDX data will simplify tooling to authenticate files and reduce the chances that signatures will be accedentally removed from an SPDX dataset.</p><h2>Compatibility</h2><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><h2>Status</h2><p><strong><ins class="diffchange diffchange-inline">Rejected</ins></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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><p>The S/MIME and x.509 certificates are widely deployed, well tested and standardized way to provide cryptographically secure message authentication and non-repudiation. The relevant documents are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually.</p><p>The SPDX data would be embedded in the file in clear text which means specific tooling is only needed when signature authentication is required. Combining the signature and the SPDX data will simplify tooling to authenticate files and reduce the chances that signatures will be accedentally removed from an SPDX dataset.</p><h2>Compatibility</h2><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td></tr>
</table>Pezrahttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1342&oldid=prevPezra at 17:40, 28 February 20122012-02-28T17:40:38Z<p></p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 17:40, 28 February 2012</td>
</tr><tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><p>The S/MIME and x.509 certificates are <del class="diffchange diffchange-inline">a standard, </del>widely deployed <del class="diffchange diffchange-inline">and </del>well tested way to provide cryptographically secure message authentication<del class="diffchange diffchange-inline">, </del>and non-repudiation. The <del class="diffchange diffchange-inline">standards </del>are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually. <del class="diffchange diffchange-inline">Because the signed </del>data <del class="diffchange diffchange-inline">is </del>embedded in the file in clear text specific tooling is only needed when signature authentication is required.</p><h2>Compatibility</h2><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed inside of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><p>The S/MIME and x.509 certificates are widely deployed<ins class="diffchange diffchange-inline">, </ins>well tested <ins class="diffchange diffchange-inline">and standardized </ins>way to provide cryptographically secure message authentication and non-repudiation. The <ins class="diffchange diffchange-inline">relevant documents </ins>are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually.<ins class="diffchange diffchange-inline"></p><p>The SPDX </ins>data <ins class="diffchange diffchange-inline">would be </ins>embedded in the file in clear text <ins class="diffchange diffchange-inline">which means </ins>specific tooling is only needed when signature authentication is required<ins class="diffchange diffchange-inline">. Combining the signature and the SPDX data will simplify tooling to authenticate files and reduce the chances that signatures will be accedentally removed from an SPDX dataset</ins>.</p><h2>Compatibility</h2><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td></tr>
</table>Pezrahttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1341&oldid=prevPezra at 20:55, 17 January 20122012-01-17T20:55:47Z<p></p>
<table class='diff diff-contentalign-left'>
<tr style='vertical-align: top;'>
<td colspan='1' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='1' style="background-color: white; color:black; text-align: center;">Revision as of 20:55, 17 January 2012</td>
</tr><tr><td colspan='2' style='text-align: center;'><div class="mw-diff-empty">(No difference)</div>
</td></tr></table>Pezrahttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1340&oldid=prevPezra at 20:44, 17 January 20122012-01-17T20:44:25Z<p></p>
<table class='diff diff-contentalign-left'>
<tr style='vertical-align: top;'>
<td colspan='1' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='1' style="background-color: white; color:black; text-align: center;">Revision as of 20:44, 17 January 2012</td>
</tr><tr><td colspan='2' style='text-align: center;'><div class="mw-diff-empty">(No difference)</div>
</td></tr></table>Pezrahttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1339&oldid=prevPezra at 20:43, 17 January 20122012-01-17T20:43:07Z<p></p>
<table class='diff diff-contentalign-left'>
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 20:43, 17 January 2012</td>
</tr><tr><td colspan="2" class="diff-lineno">Line 1:</td>
<td colspan="2" class="diff-lineno">Line 1:</td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><h2>Status</h2></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><h2>Status</h2><ins class="diffchange diffchange-inline"><p></ins><strong>Draft</strong><ins class="diffchange diffchange-inline"></p></ins><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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><h2>Proposal</h2><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed <ins class="diffchange diffchange-inline">inside </ins>of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><p>The S/MIME and x.509 certificates are a standard, widely deployed and well tested way to provide cryptographically secure message authentication, and non-repudiation. The standards are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually. Because the signed data is embedded in the file in clear text specific tooling is only needed when signature authentication is required.</p><h2>Compatibility</h2><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><strong>Draft</strong></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><h2>Issue</h2></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><h2>Proposal</h2></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. <del class="diffchange diffchange-inline"> </del>This format embeds a clear text version of the file to be signed <del class="diffchange diffchange-inline">in side </del>of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><p>The S/MIME and x.509 certificates are a standard, widely deployed and well tested way to provide cryptographically secure message authentication, and non-repudiation. The standards are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually. <del class="diffchange diffchange-inline"> </del>Because the signed data is embedded in the file in clear text specific tooling is only needed when signature authentication is required.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><h2>Compatibility</h2></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. <del class="diffchange diffchange-inline"> </del>However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div></div></td></tr>
</table>Pezrahttps://wiki.spdx.org/index.php?title=Technical_Team/Proposals/2012-01-17/Signed_SPDX_data&diff=1338&oldid=prevPezra at 20:41, 17 January 20122012-01-17T20:41:41Z<p></p>
<p><b>New page</b></p><div><h2>Status</h2><br />
<strong>Draft</strong><br />
<br />
<h2>Issue</h2><br />
<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, <a href="https://bugs.linuxfoundation.org/show_bug.cgi?id=980">issue 980</a>.</p><br />
<br />
<h2>Proposal</h2><br />
<br />
<p>Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the <code>multipart/signed</code> format. This format embeds a clear text version of the file to be signed in side of a text based wrapper which contains the cryptographic signature. SPDX consumers would be required to accept signed SPDX files, but would <strong>not</strong> be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.</p><br />
<br />
<p>The S/MIME and x.509 certificates are a standard, widely deployed and well tested way to provide cryptographically secure message authentication, and non-repudiation. The standards are <a href="http://tools.ietf.org/html/rfc3851">RFC 3851</a> and <a href="http://tools.ietf.org/html/rfc3850">RFC 3850</a>. The resulting files are easy to process using widely available tooling both programmatically and manually. Because the signed data is embedded in the file in clear text specific tooling is only needed when signature authentication is required.</p><br />
<br />
<h2>Compatibility</h2><br />
<br />
<p>This proposal will produce files that are not backwards compatible. Specifically a signed filed will not be readable by SPDX-1.0 compliant consumers. However, files produced by SPDX-1.0 compliant tools will continue to be valid SPDX files and tools that support signing, as described above, will be able to consume SPDX-1.0 files with no changes.</p></div>Pezra