Technical Team/Proposals/2012-06-06/Detached Signed SPDX Files - Revision history

MartinMichlmayr: Convert to MediaWiki syntax

2013-03-07T11:30:28Z

Convert to MediaWiki syntax

Eaw at 01:27, 12 March 2012

2012-03-12T01:27:04Z

Eaw at 17:57, 6 March 2012

2012-03-06T17:57:20Z

Eaw at 17:54, 6 March 2012

2012-03-06T17:54:14Z

Eaw at 17:48, 6 March 2012

2012-03-06T17:48:27Z

Eaw at 17:45, 6 March 2012

2012-03-06T17:45:13Z

Eaw at 17:37, 6 March 2012

2012-03-06T17:37:23Z

New page

<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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. </li><li>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  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> </p>

← Older revision		Revision as of 11:30, 7 March 2013
Line 1:		Line 1:
−	~~<p> </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 state that~~</p><ol><li><strong>~~Signing Convention:~~ </strong>~~SPDX producers~~ <strong>~~may~~ </strong> ~~cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440.~~ ~~This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file. ~~ </li><li><strong>~~Signature File Naming Convention:~~ </strong>~~The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.~~</li><li><strong>~~Signature File Renaming:~~ </strong>~~Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively. ~~ </li><li><strong>~~Consumption Optional:~~ </strong>~~SPDX consumers~~ <strong>~~may~~</strong> ~~accept or ignore SPDX signature files.~~ </li><li><strong>~~Production Optional:~~ </strong>~~SPDX producers would have the option of signing SPDX files but would~~ <strong>~~not~~</strong> ~~be required to do so. ~~ </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><strong>~~Leverage Existing Tools:~~ </strong>~~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.~~ </li><li><strong>~~Tooling Simplication:~~ </strong>~~It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues. ~~ ~~A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.~~</li><li><strong>~~Community Standard:~~ </strong>~~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><strong>~~Misplaced Signatures:~~ </strong>~~Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file~~</li><li><strong>~~Signature Correlation:~~ </strong>~~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><strong>~~Misplaced Signatures -- Existing Archive Formats: ~~ </strong>~~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. ~~ ~~This solution is proposed in ~~<a href="http:~~/~~/spdx.org/wiki~~/~~2012-mar-11-spdx-file-aggregation">Proposal~~ 2012-Mar-~~11 SPDX File Aggregation</a></li><li><strong>~~Signature Correlation - Signature File Naming Convention:~~ </strong>~~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 are~~ ~~trivially 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> </p>~~	+	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, [https://bugs.linuxfoundation.org/show_bug.cgi?id=980 issue 980].
		+
		+	==Proposal==
		+
		+	Modify the spec to state that
		+
		+	# '''Signing Convention: '''SPDX producers '''may ''' cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.
		+	# '''Signature File Naming Convention: '''The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.
		+	# '''Signature File Renaming: '''Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.
		+	# '''Consumption Optional: '''SPDX consumers '''may''' accept or ignore SPDX signature files.
		+	# '''Production Optional: '''SPDX producers would have the option of signing SPDX files but would '''not''' be required to do so.
		+
		+	==Example==
		+
		+	===SPDX file===
		+
		+	SPDXVersion: SPDX-1.0
		+	DataLicense: PDDL-1.0
		+	Creator: Person: Ed Warnicke
		+
		+	===Signed SPDX file===
		+
		+
		+	-----BEGIN PGP SIGNATURE-----
		+	Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
		+	Comment: GPGTools - http://gpgtools.org
		+	iEYEABECAAYFAk9WSn0ACgkQpqzn7Jq4hlCfYACbBelTUtjOGAYrSBXEODD9Ukpo
		+	vuAAn2gLkGsGOntkUTERnISOyOoBJxlT
		+	=JxE7
		+	-----END PGP SIGNATURE -----
		+
		+	===Command sign an SPDX file===
		+
		+	$ gpg --armor --output example.spdx.sign --detach-sig example.spdx
		+
		+	==Advantages==
		+
		+	Detaching the signature in the SPDX file has several advantages.
		+
		+	# '''Leverage Existing Tools: '''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.
		+	# '''Tooling Simplication: '''It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues. A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.
		+	# '''Community Standard: '''It follows the convention already being followed by kernel.org, mavencentral, the apache foundation, and most packagers.
		+
		+	==Disadvantages==
		+
		+	Detaching the signature in the SPDX file could lead to
		+
		+	# '''Misplaced Signatures: '''Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file
		+	# '''Signature Correlation: '''Separation of the signature file from the SPDX file introduces the need to correlate signature files with SPDX files.
		+
		+	<div>
		+
		+	==Responses to Disadvantages==
		+
		+	# '''Misplaced Signatures -- Existing Archive Formats: '''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. This solution is proposed in [[Technical_Team/Proposals/2012-Mar-11_SPDX_File_Aggregation]]
		+	# '''Signature Correlation - Signature File Naming Convention: '''The SPDX signature file naming and placement conventions in the proposal eliminate concerns about correlation.
		+
		+	</div>
		+
		+	==Compatibility==
		+
		+	This proposal will produce files that are trivially 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.
		+
		+	[[Category:Technical]]

← Older revision		Revision as of 01:27, 12 March 2012
Line 1:		Line 1:
−	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li><strong>Signature File Renaming: </strong>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li><strong>Consumption Optional: </strong>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li><strong>Production Optional: </strong>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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><strong>Leverage Existing Tools: </strong>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. </li><li><strong>Tooling Simplication: </strong>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.</li><li><strong>Community Standard: </strong>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><strong>Misplaced Signatures: </strong>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li><strong>Signature Correlation: </strong>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><strong>Misplaced Signatures -- Existing Archive Formats:  </strong>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><strong>Signature Correlation - Signature File Naming Convention: </strong>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 are trivially 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> </p>	+	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li><strong>Signature File Renaming: </strong>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li><strong>Consumption Optional: </strong>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li><strong>Production Optional: </strong>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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><strong>Leverage Existing Tools: </strong>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. </li><li><strong>Tooling Simplication: </strong>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.</li><li><strong>Community Standard: </strong>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><strong>Misplaced Signatures: </strong>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li><strong>Signature Correlation: </strong>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><strong>Misplaced Signatures -- Existing Archive Formats:  </strong>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.  This solution is proposed in <a href="http://spdx.org/wiki/2012-mar-11-spdx-file-aggregation">Proposal 2012-Mar-11 SPDX File Aggregation</a></li><li><strong>Signature Correlation - Signature File Naming Convention: </strong>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 are trivially 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> </p>

← Older revision		Revision as of 17:57, 6 March 2012
Line 1:		Line 1:
−	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li><strong>Signature File Renaming: </strong>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li><strong>Consumption Optional: </strong>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li><strong>Production Optional: </strong>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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><strong>Existing Tools: </strong>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. </li><li><strong>Tooling Simplication: </strong>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.</li><li><strong>Community Standard: </strong>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><strong>Misplaced Signatures: </strong>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li><strong>Signature Correlation: </strong>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><strong>Misplaced Signatures -- Existing Archive Formats:  </strong>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><strong>Signature Correlation - Signature File Naming Convention: </strong>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 are trivially 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> </p>	+	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li><strong>Signature File Renaming: </strong>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li><strong>Consumption Optional: </strong>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li><strong>Production Optional: </strong>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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><strong>Leverage Existing Tools: </strong>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. </li><li><strong>Tooling Simplication: </strong>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.</li><li><strong>Community Standard: </strong>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><strong>Misplaced Signatures: </strong>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li><strong>Signature Correlation: </strong>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><strong>Misplaced Signatures -- Existing Archive Formats:  </strong>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><strong>Signature Correlation - Signature File Naming Convention: </strong>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 are trivially 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> </p>

← Older revision		Revision as of 17:54, 6 March 2012
Line 1:		Line 1:
−	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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. </li><li>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  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> </p>	+	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li><strong>Signature File Renaming: </strong>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li><strong>Consumption Optional: </strong>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li><strong>Production Optional: </strong>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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><strong>Existing Tools: </strong>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. </li><li><strong>Tooling Simplication: </strong>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  A tool maker who just wants to focus on processing SPDX data does not need to worry about knowing how to unpack a wrapper.</li><li><strong>Community Standard: </strong>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><strong>Misplaced Signatures: </strong>Separation of the signature file from the SPDX file makes it possible for the signature to become separated from the SPDX file</li><li><strong>Signature Correlation: </strong>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><strong>Misplaced Signatures -- Existing Archive Formats:  </strong>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><strong>Signature Correlation - Signature File Naming Convention: </strong>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 are trivially 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> </p>

@@ Line 1: / Line 1: @@
-<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>
+<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>
 <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>

← Older revision		Revision as of 17:45, 6 March 2012
Line 1:		Line 1:
−	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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. </li><li>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  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> </p>	+	<p> </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 state that</p><ol><li><strong>Signing Convention: </strong>SPDX producers <strong>may </strong> cryptographically sign SPDX files using the PGP detached signature format as specified in RFC 2440. This format does not modify the original SPDX, but rather creates a separate <filename>.sig or <filename>.sign file containing a signature for the original file.  </li><li><strong>Signature File Naming Convention: </strong>The signature filename should be either <filename>.sig or <filename>.sign and be in the same directory as the SPDX file.</li><li>Renames of an SPDX file from <filename1> to <filename2> should also rename any <filename1>.sig or <filename1>.sign files to <filename2>.sig or <filename2>.sign respectively.  </li><li>SPDX consumers <strong>may</strong> accept or ignore SPDX signature files. </li><li>SPDX producers would have the option of signing SPDX files but would <strong>not</strong> be required to do so.  </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. </li><li>It makes tooling for SPDX easier because it allows issues of file authentication to be considered orthogonally from other issues.  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> </p>