editorial: clarify build platform reqs in levels.md

Update levels.md to align with requirements.md and to make it more clear
how the requirements on the build platform differ between levels:

Build L1:

- Problem: levels.md incorrectly implied that that the *platform* must
  generate the provenance.

- Fix: Update levels.md to say that provenance must simply "exist",
  matching the wording on requirements.md. Also simplify the wording
  while we're at it.

Build L2:

- Problem: The phrase "ensures the trustworthiness of the provenance"
  could be misread as being a general requirement for L2 builds, whereas
  the intention was just as a qualifier on "some equivalent platform."
  Also, the intent of the build platform generating and signing the
  provenance was unclear, further exacerbating the problem above.

- Fix: Simplify this bullet to focus on the intent of (a) builds running
  on dedicated infrastructure and (b) tying the provenance to that
  infrastructure.

Fixes #863.

Signed-off-by: Mark Lodato <lodato@google.com>

docs/spec/v1.0/levels.md

@@ -100,9 +100,8 @@ SLSA---other than tamper protection---without changing their build workflows.
 -   Software producer follows a consistent build process so that others can form
     expectations about what a "correct" build looks like.
 
--   Build platform automatically generates [provenance] describing how the
-    artifact was built, including: what entity built the package, what build
-    process they used, and what the top-level input to the build were.
+-   [Provenance] exists describing how the artifact was built, including the
+    build platform, build process, and top-level inputs.
 
 -   Software producer distributes provenance to consumers, preferably using a
     convention determined by the package ecosystem.
@@ -151,10 +150,9 @@ platform itself required by [Build L3].
 
 All of [Build L1], plus:
 
--   The build runs on a hosted build platform that generates and signs[^sign] the
-    provenance itself. This may be the original build, an after-the-fact
-    reproducible build, or some equivalent platform that ensures the
-    trustworthiness of the provenance.
+-   Build platform runs on dedicated infrastructure, not an individual's
+    workstation, and the provenance is tied to that infrastructure through
+    a digital signature[^sign].
 
 -   Downstream verification of provenance includes validating the authenticity
     of the provenance.
@@ -178,8 +176,9 @@ All of [Build L1], plus:
 </section>
 <section id="build-l3">
 
-[^sign]: Alternate means of verifying the authenticity of the provenance are
-    also acceptable.
+[^sign]: Usually this means that the provenance is signed by a key that is only
+    accessible to the build platform, but alternate means of verifying the
+    authenticity of the provenance are also acceptable.
 
 ### Build L3: Hardened builds