formatting fixes and typos

Signed-off-by: Marina Moore <mnm678@gmail.com>

Author: mnm678

candidate-fulcio-tap.md

@@ -10,7 +10,7 @@
 * TUF-Version:
 
 # Abstract
-In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification.
+In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore's Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification.
 
 # Motivation
 Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key, including secure storage of the key over a long period of time to prevent it leaking to an attacker. However, many developers that upload packages to large TUF adoptions, including the Python Package Index (PyPI), manage small or under-resourced projects and do not want the extra burden of having to protect a private key for use in deployment.
@@ -28,15 +28,15 @@ In this TAP, we instead propose use of the sigstore project. Sigstore has a grow
 In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to any OIDC identity, including developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing keys and uses certificates to bind these keys to an identity backed by OIDC authentication. Because the ephemeral keys listed in the certificates are short-lived, the developer will not be responsible for protecting signing keys in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing.
 
 ## Delegation format
-In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format:
+In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a "sigstore-oidc" keytype for a KEY with the following format:
 
 ```
 {
-  “keytype”: “sigstore-oidc",
-  “scheme”: "Fulcio",
-  “keyval”: {
-    “identity”: IDENTITY,
-    “issuer”: ISSUER
+  "keytype": "sigstore-oidc",
+  "scheme": "Fulcio",
+  "keyval": {
+    "identity": IDENTITY,
+    "issuer": ISSUER
   }
 }
 ```
@@ -47,12 +47,12 @@ The root certificate or certificate chain for the Fulcio server MUST be obtained
 
 
 ## Signature format
-A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘bundle’ field to ‘signatures’ to replace `sig` for this key type. With this field, signatures would look like:
+A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a 'bundle' field to 'signatures' to replace `sig` for this key type. With this field, signatures would look like:
 
 ```
 "signatures" : [
     { "keyid" : KEYID,
-      “bundle”:  BUNDLE }
+      "bundle":  BUNDLE }
       , ... ]
 ```
 Where BUNDLE is an object that contains the verification information (transparency log references or timestamps), Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log.
@@ -76,14 +76,14 @@ Most of these steps SHOULD be done automatically using a tool (such as Sigstore)
 ## Verification
 This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys and the certificate log public key using a secure out of band method prior to verifying the signature and associated certificate.
 
-While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verifcation.
+While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verification.
 
 Verification includes the following steps:
 
 * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root.
-* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key
+* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key.
 * Verify the signature on the TUF metadata using the key from the Fulcio certificate.
-* Verify the SET to ensure that the signature was signed during certificate validity
+* Verify the SET to ensure that the signature was signed during certificate validity.
 
 Similar to signing, this verification SHOULD be done with existing Sigstore tooling.
 Periodically the repository SHOULD perform online verification of all Rekor uses.
@@ -93,19 +93,19 @@ Online clients MAY additionally perform online verification. This process is des
 
 Online verification requires the following steps:
 
-* Obtain the most recent Rekor signed tree head.
-	* Query the Rekor transparancy log for a consistency proof against your current signed tree head.
+1. Obtain the most recent Rekor signed tree head.
+	* Query the Rekor transparency log for a consistency proof against your current signed tree head.
 	* Verify this consistency proof.
-	* Persist the newest signed tree head
-* Query the Rekor transparency log for a proof of inclusion against the certificate and TUF metadata
-* Verify this inclusion proof.
-* Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1
+	* Persist the newest signed tree head.
+1. Query the Rekor transparency log for a proof of inclusion against the certificate and TUF metadata.
+1. Verify this inclusion proof.
+1. Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1.
 
 Online verification SHOULD be performed periodically by repositories and MAY be performed by clients.
 
 Developers SHOULD monitor the transparency log (TL)  and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity.
 
-In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log.
+In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don't use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log.
 
 If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revoke its certificate and distribute a new certificate in the TUF Sigstore root, and inform any affected clients of the compromise.
 
@@ -121,14 +121,14 @@ If only one of the transparency logs is compromised, the attacker will not be ab
 
 If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata.
 
-By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that online verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance.
+By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, existing uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that online verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance.
 
 
 # Backwards Compatibility
 
 Clients that do not recognize Fulcio certs will not be able to validate signatures from Fulcio certs, but they will be able to parse the metadata.
 
-‘Bundle’ is a new field added to ‘signatures’. Clients that do not recognize Fulcio certs will ignore this field by default.
+'Bundle' is a new field added to 'signatures'. Clients that do not recognize Fulcio certs will ignore this field by default.
 
 # Augmented Reference Implementation