Skip to content

Commit

Permalink
fixes #325 by updating references to The Notary Project
Browse files Browse the repository at this point in the history
Signed-off-by: Zach Rhoads <[email protected]>
  • Loading branch information
zr-msft committed Sep 12, 2023
1 parent 9b88d58 commit 2285521
Show file tree
Hide file tree
Showing 4 changed files with 11 additions and 12 deletions.
17 changes: 8 additions & 9 deletions content/en/docs/faq.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
---
title: "Frequently asked questions"
description: "Frequently asked questions about Notary Project"
description: "Frequently asked questions about the Notary Project"
type: docs
weight: 7
---

## What registries are compatible with Notation?
## What registries are compatible with the Notary Project OCI signature specification?

The following registries are compatible with Notation for artifact signing and verification:
The following registries are compatible with the Notary Project OCI signature specification:

- [Azure Container Registry](https://learn.microsoft.com/azure/container-registry/?wt.mc_id=azurelearn_inproduct_oss_notaryproject)
- [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)
Expand All @@ -24,7 +24,7 @@ The following registries are compatible with Notation for artifact signing and v

**Q: Why JWT `exp` and `iat` claims are not used?**

**A:** Unlike JWT which always contains a JSON payload, the Notary Project signature envelope can support payloads other than JSON, like binary. Reusing the JWT payload structure and claims, limits the Notary Project signature JWS envelope to only support JSON payload, which is undesirable. Also, reusing JWT claims requires following the same claim semantics as defined in JWT specifications. The [`exp`](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) claim requires that the verifier MUST reject the signature if the current time equals or is greater than `exp`, where as Notation allows verification policy to define how expiry is handled.
**A:** Unlike JWT which always contains a JSON payload, [Notary Project OCI Signature Specification](https://github.com/notaryproject/notaryproject/blob/v1.0.0/specs/signature-specification.md) envelope can support payloads other than JSON, like binary. Reusing the JWT payload structure and claims, limits the signature envelope to only support JSON payload, which is not extendable. Also, reusing JWT claims requires following same claim semantics as defined in JWT specifications. The [`exp`](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) claim requires that verifier MUST reject the signature if current time equals or is greater than `exp`, where as the Notary Project's [trust store and trust policy](https://github.com/notaryproject/notaryproject/blob/v1.0.0/specs/trust-store-trust-policy.md) allows verification policy to define how expiry is handled.

## Signature specification

Expand Down Expand Up @@ -56,15 +56,14 @@ This has implication such as an end user with CA issued certificate can masquera

## Trust store and trust policy

**Q: Does Notation supports `n` out of `m` signatures verification requirement?**
**Q: Does the Notary Project trust policy support `n` out of `m` signatures verification requirement?**

**A:** Notation doesn't support `n` out of `m` signature requirement verification scheme.
**A:** The Notary Project doesn't support n out m signature requirement verification scheme.
Signature verification workflow succeeds if verification succeeds for at least one signature.

**Q: Does Notation support overriding of revocation endpoints to support signature verification in disconnected environments?**
**Q: Does the Notary Project support overriding of revocation endpoints to support signature verification in disconnected environments?**

**A:** TODO: Update after verification extensibility spec is ready.
Not natively supported but a user can configure `revocationValidations` to `skip` and then use extended validations to check for revocation.
**A:** Not natively supported but a user can configure `revocationValidations` to `skip` and then use extended validations to check for revocation.

**Q: Why user needs to include a complete certificate chain (leading to root) in the signature?**

Expand Down
2 changes: 1 addition & 1 deletion content/en/docs/user-guides/how-to/_index.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: How-to guides
description: The collection of guides for configuring and using Notation
description: The collection of guides for configuring and using Notation CLI
weight: 3
---

2 changes: 1 addition & 1 deletion content/en/docs/user-guides/tutorials/_index.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: Tutorials
description: A set of guides that walks you through using the different capabilities and features of Notation
description: A set of guides that walks you through using the different capabilities and features of the Notary Project
weight: 2
---

2 changes: 1 addition & 1 deletion content/en/docs/user-guides/tutorials/trust-policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ type: docs
weight: 1
---

As part of the process to verify a container image with notary, you need to configure the trust policy to specify trusted identities that sign the artifacts, and the level of signature verification to use. For more details, see [trust policy spec](https://github.com/notaryproject/specifications/blob/main/specs/trust-store-trust-policy.md#trust-store).
As part of the process to verify a container image with Notation, you need to configure the trust policy to specify trusted identities that sign the artifacts, and the level of signature verification to use. For more details, see [trust policy spec](https://github.com/notaryproject/notaryproject/blob/v1.0.0/specs/trust-store-trust-policy.md#trust-store).

This tutorial shows you how to create a trust policy with different trusted identities and levels of signature verification.

Expand Down

0 comments on commit 2285521

Please sign in to comment.