editorial: declare a preference for TL-based signing (#916)

We encourage the use of transparency log based signing methodologies
because they provide observability which makes it easier to detect key
compromise, and constraints (time stamping) which make detected
compromises easier to remediate.

We prefer them, rather than require them, because there is no one-size
fits all solution given numerous constraints on operational load,
confidentiality, etc.

Fixes: #727 

 Signed-off-by: Joshua Lock <joshua.lock@uk.verizon.com>

docs/spec/v1.0/requirements.md

@@ -194,11 +194,17 @@ provenance attestation in order to:
 -   *Define trust:* Identify the build platform and other entities that are
     necessary to trust in order to trust the artifact they produced.
 
-This SHOULD be through a digital signature from a private key accessible only to
-the build platform component that generated the provenance attestation.
+This SHOULD be through a digital signature from a private key accessible only
+to the build platform component that generated the provenance attestation.
 
-This allows the consumer to trust the contents of the provenance attestation,
-such as the identity of the build platform.
+While many constraints affect choice of signing methodologies, it is
+RECOMMENDED that build platforms use signing methodologies which improve the
+ability to detect and remediate key compromise, such as methods which rely on
+transparency logs or, when transparency isn't appropriate, time stamping
+services.
+
+Authenticity allows the consumer to trust the contents of the provenance
+attestation, such as the identity of the build platform.
 
 *Accuracy:* The provenance MUST be generated by the control plane (i.e. within
 the trust boundary [identified in the provenance]) and not by a tenant of the