Add minor doc fixes (#280)

* Fix typos in overview Signed-off-by: Colleen Murphy <[email protected]> * Add back descriptive content on cert issuing As part of doc enhancements in b57dc16, the description in step 7 was removed. Although the final step is simple and the diagram and section header are clear, it is jarring for the final step to be inconsistent with the others by having no text body. It is moreover unfriendly to screen readers since there is no context for the diagram. This change adds the brief description back for the sake of readability. Signed-off-by: Colleen Murphy <[email protected]> --------- Signed-off-by: Colleen Murphy <[email protected]>
sigstore · Dec 15, 2023 · 1110d77 · 1110d77
1 parent 67b9b74
commit 1110d77
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 2 deletions.
diff --git a/content/en/about/overview.md b/content/en/about/overview.md
@@ -50,11 +50,11 @@ A Sigstore client, such as Cosign, requests a certificate from our code-signing
 
 You don’t have to manage signing keys, and Sigstore services never obtain your private key. The public key that a Sigstore client creates gets bound to the issued certificate, and the private key is discarded after a single signing.
 
-After the client signs the artifact, the artifact's digest, signature and certificate are persisted in a transparency log: an immutable, append-only ledger known as Rekor. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads and artifact can confirm that the certificate was valid at the time of signing.
+After the client signs the artifact, the artifact's digest, signature and certificate are persisted in a transparency log: an immutable, append-only ledger known as Rekor. With this log, signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used, and someone who downloads an artifact can confirm that the certificate was valid at the time of signing.
 
 For verifying an artifact, a Sigstore client will verify the signature on the artifact using the public key from the certificate, verify the identity in the certificate matches an expected identity, verify the certificate's signature using Sigstore's root of trust, and verify proof of inclusion in Rekor. Together, verification of this information tells the user that the artifact comes from its expected source and has not been tampered with after its creation.
 
-For more information on the modules that make up Sigstore, review [Toolling]({{< relref "about/tooling">}}).
+For more information on the modules that make up Sigstore, review [Tooling]({{< relref "about/tooling">}}).
 
 ## How to use Sigstore
 

diff --git a/content/en/certificate_authority/certificate-issuing-overview.md b/content/en/certificate_authority/certificate-issuing-overview.md
@@ -113,4 +113,6 @@ See [Certificate Transparency Log Information](https://github.com/sigstore/fulci
 
 ## 7 — Return certificate to client
 
+Finally, the certificate and SCT are both returned to the client.
+
 ![Fulcio return the certificate to the client](/fulcio-7-return-to-client.png)