Merge pull request #79 from slsa-framework/TomHennen-patch-1

Allow a service other than the 'build service' to generate provenance

requirements.md

@@ -294,15 +294,29 @@ all the other requirements.
 
 The provenance's authenticity and integrity can be verified by the consumer.
 This SHOULD be through a digital signature from a private key accessible only to
-the build service.
+the service generating the provenance.
 
 <td> <td>✓<td>✓<td>✓
 <tr id="service-generated">
 <td>Service Generated
 <td>
 
-The provenance was populated by the build service, not by user-provided tooling
-running on top of the service.
+The data in the provenance MUST be obtained from the build service (either because
+the generator _is_ the build service or because the provenance generator reads the
+data directly from the build service).
+    
+Regular users of the service MUST NOT be
+able to inject or alter the contents, except as noted below.
+
+The following provenance fields MAY be generated by the user-controlled build
+steps:
+
+*   The output artifact hash from [Identifies Artifact](#identifies-artifact).
+    *   Reasoning: This only allows a "bad" build to falsely claim that it
+        produced a "good" artifact. This is not a security problem because the
+        consumer MUST accept only "good" builds and reject "bad" builds.
+*   The "reproducible" boolean and justification from
+    [Reproducible](#reproducible).
 
 <td> <td>✓<td>✓<td>✓
 <tr id="non-falsifiable">
@@ -311,6 +325,8 @@ running on top of the service.
 
 Provenance cannot be falsified by the build service's users.
 
+NOTE: This requirement is a stricter version of [Service Generated](#service-generated).
+    
 *   The provenance signing key MUST be stored in a secure key management system
     accessible only to the build service account.
 *   The provenance signing key MUST NOT be accessible to the environment running