THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

Difference between revisions of "Technical Team/Proposals/2012-01-17/Signed SPDX data"

From SPDX Wiki
Jump to: navigation, search
Line 1: Line 1:
<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 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>
+
<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, 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>

Revision as of 17:40, 28 February 2012

Status

Draft

Issue

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>.

Proposal

Modify the spec to allow SPDX producers to cryptographically sign SPDX files with an x.509 certificate using the multipart/signed 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 not be required to authenticate any signatures. SPDX producers would have the option of signing SPDX files but would not be required to do so.

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.

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.

Compatibility

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.