fixed typo in overview.md

content/en/signing/overview.md

@@ -42,9 +42,9 @@
 
 #### Verifying identity and signing the artifact
 
 1) An in-memory public/private keypair is created. 
 2) The identity token is retrieved.
 3) Sigstore's certificate authority verifies the identity token of the user signing the artifact and issues a certificate attesting to their identity. The identity is bound to the public key. Decrypting with the public key will prove the identity of the private keyholder. 
 4) For security, the private key is destroyed shortly after and the short-lived identity certificate expires. Users who wish to verify the software will use the transparency log entry, rather than relying on the signer to safely store and manage the private key.
 
 #### Recording signing event
@@ -53,7 +53,7 @@
 
 #### Verifying the signed artifact
 
 When a software consumer wants to verify the software’s signature, Sigstore compares a tuple of signature, key/certificate, and artifact from the timestamped object against the timestamped Rekor entry. If they match, it confirms that the signature is valid because the user knows that the expected software creator, whose identity was certified at the moment of signing, published the software artifact in their possession. The entry in Rekor’s immutable transparency log means that the signer will be monitoring the log for occurrences of their identity and will know if there is an unexpected signing event. 
 
 ### On Google Cloud Platform
 
@@ -88,9 +88,9 @@
 
 ## Custom infrastructure
 
-If you're running your own sigtore services flags are available to set your own endpoint's, e.g
+If you're running your own sigstore services flags are available to set your own endpoint's, e.g
 
 ```
  cosign sign --oidc-issuer "https://oauth2.example.com/auth" \
                         --fulcio-url "https://fulcio.example.com" \
                         --rekor-url "https://rekor.example.com"  \