From 33576d52946f1a148e25a02c07cfe540eb59a60b Mon Sep 17 00:00:00 2001 From: Pritesh Bandi Date: Tue, 11 Jan 2022 14:29:28 -0800 Subject: [PATCH 1/3] Added signing and verification workflows - Added detailed steps for signature verification - Added certificate requirements Co-authored-by: Milind Gokarn Signed-off-by: Pritesh Bandi --- signature-specification.md | 26 ++++- signing-and-verification-workflow.md | 56 +++++++++++ trust-store-trust-policy-specification.md | 113 +++++++++++++++++++--- 3 files changed, 181 insertions(+), 14 deletions(-) create mode 100644 signing-and-verification-workflow.md diff --git a/signature-specification.md b/signature-specification.md index 9d09f419..b466bb36 100644 --- a/signature-specification.md +++ b/signature-specification.md @@ -18,7 +18,7 @@ The signature manifest has an artifact type which specifies it's a Notary V2 sig - **`artifactType`** (*string*): This REQUIRED property references the Notary version of the signature: `application/vnd.cncf.notary.v2.signature`. - **`blobs`** (*array of objects*): This REQUIRED property contains collection of only one [artifact descriptor](https://github.com/oras-project/artifacts-spec/blob/main/descriptor.md) referencing signature envelope. - - **`mediaType`** (*string*): This REQUIRED property contains media type of signature envelope blob. The supported value is `application/jose+json` + - **`mediaType`** (*string*): This REQUIRED property contains media type of signature envelope blob. The supported value is `application/jose+json` - **`subject`** (*descriptor*): A REQUIRED artifact descriptor referencing the signed manifest, including, but not limited to image manifest, image index, oras-artifact manifest. - **`annotations`** (*string-string map*): This OPTIONAL property contains arbitrary metadata for the artifact manifest. It can be used to store information about the signature. @@ -204,7 +204,7 @@ Since Notary v2 restricts one signature per signature envelope, the compliant si 4. Signing certificate MUST be a valid codesigning certificate. 5. Only JWS JSON flattened format is supported. See 'Signature Envelope' section. -## Signature Algorithms +## Signature Algorithm Requirements The implementation MUST support the following set of algorithms: 1. RSASSA-PSS with SHA-256 @@ -230,6 +230,28 @@ The signing certificate's public key algorithm and size MUST be used to determin | EC | 384 | ECDSA on secp384r1 with SHA-384 | | EC | 512 | ECDSA on secp521r1 with SHA-512 | +### Certificate Requirements + +The signing certificate MUST meet the following minimum requirements: + +- The signing certificate MUST satisfy the following constraints: + - The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). + - The extKeyUsage extension MUST be present and its value MUST be id-kp-codeSigning ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). + - If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). +- The certificate MUST abide by the following key length restrictions: + - For RSA public key, the key length MUST be 2048 bits or higher. + - For ECDSA public key, the key length MUST be 256 bits or higher. + +The timestamping certificate MUST meet the following minimum requirements: + +- The timestamping certificate MUST satisfy the following constraints: + - The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). + - The extKeyUsage extension MUST be present and and MUST be marked critical. The value of extension MUST be id-kp-timeStamping ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). + - If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). +- The certificate MUST abide by the following key length restrictions: + - For RSA public key, the key length MUST be 2048 bits or higher. + - For ECDSA public key, the key length MUST be 256 bits or higher. + ## FAQ **Q1.** How will Notary v2 support multiple signature envelope format? diff --git a/signing-and-verification-workflow.md b/signing-and-verification-workflow.md new file mode 100644 index 00000000..530f1912 --- /dev/null +++ b/signing-and-verification-workflow.md @@ -0,0 +1,56 @@ +# Signing and Verification Workflow + +This document describes how Notary v2 signs and verifies OCI artifacts. + +## Signing workflow + +The user wants to sign an OCI artifact and push the signature to a repository. + +### Prerequisite + +- User has access to the signing certificate and private key or a remote signing service through a notation plug-in. + +### Steps + +1. **Generate signature:** Using notation CLI or any other compliant signing tool, sign the OCI artifact. The signing tool should follow the following guideline. + 1. Verify that the signing certificate is valid and satisfies [certificate requirements](./signature-specification.md#certificate-requirements). + 1. Verify that the signing algorithm satisfies [algorithm requirements](./signature-specification.md#signature-algorithm-requirements). + 1. Generate signature. + 1. Generate signature using signature formats specified in [supported signature envelopes](./signature-specification.md#supported-signature-envelopes). + 1. If the user wants to timestamp the signature, obtain an [RFC-3161](https://datatracker.ietf.org/doc/html/rfc3161.html) compliant timestamp for the signature generated in the previous step. Otherwise, continue to the next step. + 1. Verify that the timestamp signing certificate satisfies [certificate requirements](./signature-specification.md#certificate-requirements). + 1. Verify that the timestamp signing algorithm satisfies [algorithm requirements](./signature-specification.md#signature-algorithm-requirements). + 1. Embed timestamp to the signature envelope. +1. **Push the signature envelope:** Push the signature envelope generated in the previous step to the repository. +1. **Generate signature artifact manifest:** As decribed in [signature specification](./signature-specification.md#storage) create the Notary v2 signature artifact manifest for the signature envelope generated in step 1. +1. **Push signature artifact manifest:** Push Notary v2 signature artifact manifest to the repository. + +The user pushes the OCI artifact to the repository before the signature generation process as the signature reference must exist for the signature push to succeed. See: [ORAS Artifact Push Validation](https://github.com/oras-project/artifacts-spec/blob/main/artifact-manifest.md#push-validation) for more info. + +## Verification workflow + +The user wants to pull an OCI artifact only if they are signed by a trusted publisher and the signature is valid. + +### Prerequisites + +- User has a fully qualified reference to an OCI artifact they want to pull. If the fully qualified artifact reference contains a tag then the user needs to resolve this tag to a digest. + + E.g. If fully qualified reference is `wabbit-networks.io/software:Latest` where `Latest` is a tag pointing to an artifact. The user must resolve `Latest` tag to a digest and construct a new artifact reference using the resolved digest `wabbit-networks.io/software@sha256:${digest}`. +- User has configured [trust store and trust policy](./trust-store-trust-policy-specification.md) required for signature verification. + +### Steps + +1. **Should Notary v2 verify the signature? :** Depending upon [trust-policy](./trust-store-trust-policy-specification.md#trust-policy) configuration, determine whether Notary v2 needs to verify the signature or not. If signature verification should be skipped for the given artifact, skip the below steps and directly jump to step 4. +1. **Get signature artifact descriptors:** Using the ORAS [Manifest Referrers API](https://github.com/oras-project/artifacts-spec/blob/main/manifest-referrers-api.md) download the Notary v2 signature artifact descriptors. The `artifactType` parameter is set to Notary v2 signature's artifact type `application/vnd.cncf.notary.v2.signature`. Note that all ORAS implementations may not support filtering using `artifactType`. +1. For each signature artifact descriptor, perform the following steps: + 1. **Get signature artifact manifest:** Download the Notary v2 signature's artifact manifest for the given artifact descriptor. + 1. **Filter signature artifact manifest:** + 1. Filter out the unsupported signature formats by comparing the signature envelope format type (`[descriptors].descriptor.mediaType`) in the signature manifest, with the supported formats defined in [signature specification](./signature-specification.md#storage). + 1. Depending upon the trust-store configuration, further filter out signature manifest. why? How? **TBD**(See [signature filtering](https://hackmd.io/@pritesh/signature_filtering)). + 1. If the artifact manifest is filtered out, skip the below steps and move to the next signature artifact descriptor(step 2.1). If all signature artifact descriptors have already been processed, fail the signature verification and exit. + 1. **Get and verify signatures:** On the filtered Notary v2 signature artifact manifest, perform the following steps: + 1. Download the signature envelope. + 1. Verify the signature envelope using trust-store and trust-policy as mentioned in [signature evaluation](./trust-store-trust-policy-specification.md#signature-evaluation) section. + 1. If signature verification fails, skip the below steps and move to the next signature artifact descriptor(step 2.1). If all signature artifact manifests have already been processed, fail the signature verification and exit. + 1. If signature verification succeeds, compare the digest derived from the given OCI artifact reference with the signed digest present in the signature envelope's payload. If digests are equal, signature verification is considered successful. Otherwise, move to the next signature artifact descriptor(step 2.1). If all signature artifact descriptors have already been processed, fail the signature verification and exit. +1. **Get OCI artifact:** Using the verified digest, download the OCI artifact. This step is not in the purview of Notary v2. diff --git a/trust-store-trust-policy-specification.md b/trust-store-trust-policy-specification.md index 3ba949cf..eb9fe177 100644 --- a/trust-store-trust-policy-specification.md +++ b/trust-store-trust-policy-specification.md @@ -181,21 +181,110 @@ The implementation must allow the user to execute custom validations. These cust ## Signature Evaluation -Precondition: The artifact is signed, trust store and trust policies are present. +### Prerequisites -1. Get the signing algorithm (hash+encryption) from the signing identity and validate that the signing algorithm is valid and allow-listed. -1. Get the public key from the signing identity and validate the artifact integrity using the public key and signing algorithm identified in the previous step. -1. Get and validate TrustStore and TrustPolicy for correctness. -1. Find the trust policy that is applicable for the given artifact. In the trust policy if `skipSignatureVerification` is set to `true`, then the signature evaluation must be skipped. -1. Get the signing identity from the signed artifact and validate it against the identities configured in the trust store of trust policy determined in step 4. The signing identity must match or lead to at least one of the trusted identities configured in the trust store. - 1. If signing identity is certificate then validate that the certificate and certificate-chain leads to self-signed root. -1. Perform [artifact expiry](#artifact-expiry) validations based on trust policy. -1. Perform [artifact revocation](#artifact-revocation) validations based on trust policy -1. Perform extended validation(If any). +- User has configured [trust store](#trust-store) and [trust policy](#trust-policy). -Here is high level uml diagram for signature evaluation: +### Steps -![uml diagram showing signature evaluation](./media/trust-store-trust-policy-evaluation.svg) +1. **Validate that the signature envelope format is supported.** + 1. Parse the signature envelope content based on the signature envelope type specified in the `[descriptors].descriptor.mediaType` attribute of the signature artifact manifest. + 1. Validate that the content type indicated by the `cty` property value of protected headers in the signature envelope is supported. +1. **Validate the signature envelope integrity.** + 1. Get the signing certificate from the parsed [signature envelope](https://github.com/notaryproject/notaryproject/blob/7b7d283038/signature-specification.md#signature-envelope). + 1. Get the signing algorithm(hash+encryption) from the signing certificate and validate that the signing algorithm satisfies [algorithm requirements](./signature-specification.md#signature-algorithm-requirements) + 1. Using the public key of the signing certificate and signing algorithm identified in the previous step, validate the integrity of the signature envelope. +1. **Validate the signature against trust policy and trust store.** + 1. Using the `scope` configured in trust policies, get the applicable trust policy. (Implementations might have this value precomputed, added it for completeness) + 1. For the applicable trust policy, **validate trust-store:** + 1. Validate that signature envelope contains complete certificate chain that start from a code signing certificate and terminate with the root certificate. Also, validate that code signing certificate satisfies [certificate requirements](./signature-specification.md#certificate-requirements). + 1. For each the trust-stores configured in applicable trust-policy perform the following steps. + 1. Validate that certificate and certificate-chain lead to a trusted certificate configured in the `x509Certs` field of trust-store. + 1. If the above verification succeeds then continue to the next step else iterate over the next trust store. If all of the trust stores have been evaluated then fail the signature validation and exit. + 1. **Validate trust policy:** + 1. If signature expiry is present in the signature envelope, using the local machine’s current time(in UTC) check whether the signature is expired or not. If the signature is not expired, continue to the next step. Otherwise, if `signatureExpiry` is set to `Enforce` then fail the signature validation and exit else log a warning and continue to the next step. + 1. Check for the timestamp signature in the signature envelope. + 1. If the timestamp exists, continue with the next step. Otherwise, store the local machine's current time(in UTC) in variables `timeStampLowerLimit` and `timeStampUpperLimit` and continue with step 3.3.c. + 1. Validate that the timestamp hash in `TSTInfo.messageImprint` matches the hash of the signature to which the timestamp was applied. + 1. Validate that the timestamp signing certificate satisfies [certificate requirements](./signature-specification.md#certificate-requirements). + 1. Validate that the timestamp signing algorithm satisfies [algorithm requirements](./signature-specification.md#signature-algorithm-requirements). + 1. Validate the `signing-certificate`([RFC-2634](https://tools.ietf.org/html/rfc2634)) or `signing-certificate-v2`([RFC-5126](https://tools.ietf.org/html/rfc5126#section-5.7.3.2)) attribute of timestamp CMS. + 1. Check whether timestamping certificate and certificate chain are valid (not expired) or not. If timestamping certificate and certificate-chain are not expired, continue to the next step. Otherwise, if `timestampExpiry` in trust-policy is configured to `Enforce` then fail the signature validation and exit, else log a warning and continue to the next step. + 1. Validate that timestamp certificate and certificate chain leads to a trusted TSA certificate configured in trust policy. + 1. Validate timestamp certificate and certificate chain revocation status using [certificate revocation evaluation](#certificate-revocation-evaluation) section as per `timestampRevocation` setting in trust-policy + 1. Retrieve the timestamp's time from `TSTInfo.genTime`. + 1. Retrieve the timestamp's accuracy. If the accuracy is explicitly specified in `TSTInfo.accuracy`, use that value. If the accuracy is not explicitly specified and `TSTInfo.policy` is the baseline time-stamp policy([RFC-3628](https://tools.ietf.org/html/rfc3628#section-5.2)), use accuracy of 1 second. Otherwise, use accuracy of 0. + 1. Calculate the timestamp range using the lower and upper limits per [RFC-3161 section 2.4.2](https://tools.ietf.org/html/rfc3161#section-2.4.2) and store the limits as `timeStampLowerLimit` and `timeStampUpperLimit` variables respectively. + 1. Check that the time range from `timeStampLowerLimit` to `timeStampUpperLimit` timestamp is entirely within the certificate's validity period. If the time range is entirely within the signing certificate and certificate chain's validity period, continue to the next step. Otherwise, If `signingIdentityExpiry` in trust-policy is configured to `Enforce` then fail the signature validation and exit else log a warning and continue to the next step. + 1. Validate signing identity(certificate and certificate chain) revocation status using [certificate revocation evaluation](#certificate-revocation-evaluation) section as per `signingIdentityRevocation` setting in trust-policy. + 1. Perform extended validation using the applicable(if any) plugin. + 1. If you have reached this step then treat the OCI artifact signature as a valid signature. + +### Certificate Revocation Evaluation + +If the certificate revocation trust-store setting is set to `skip`, skip the below steps. Otherwise, check for revocation status for certificate and certificate chain. + +1. If the revocation status of any of the certificates cannot be determined (revocation unavailable) and `signingIdentityRevocation` is set to either `enforceWithFailClose` or `warn` then log a warning and skip the below steps. Otherwise, fail the signature validation and exit. +1. If any of the certificates are revoked and `signingIdentityRevocation` is set to either `enforceWithFailOpen` or `enforceWithFailClose` then fail signature validation and exit else log a warning. + +Starting from Root to leaf certificate, for each certificate in the certificate chain, perform the following steps to check its revocation status: + +- If the certificate being validated doesn't include information OCSP or CRLs then no revocation check is performed and the certificate is considered valid(not revoked). +- If the certificate being validated includes either OCSP or CRL information, then the one which is present is used for revocation check. +- If both OCSP URLs and CDP URLs are present, then OCSP is preferred over CRLs. If revocation status cannot be determined using OCSP because of any reason such as unavailability then fallback to using CRLs for revocation check. + +#### CRLs + +There are two types of CRLs (per RFC 3280), Base CRLs and Delta CRls. + +- **Base CRLs:** Contains the revocation status of all certificates that have been issued by a given CA. BaseCRLs are signed by the certificate issuing CAs. +- **Delta CRLs:** Contains only certificates that have changed status since the last base CRL was published. Delta CRLs are signed by the certificate issuing CAs. +- **Indirect CRLs:** Special Case in which BaseCRLs and Delta CRLs are not signed by the certificate issuing CAs, instead they are signed with a completely different certificate. + +Notary v2 MUST support BaseCRLs and Delta CRLs. Notary v2 MAY support Indirect CRLs. Notary v2 supports only HTTP CRL URLs. + +Implementations MAY add support for caching CRLs and OCSP response to improve availability, latency and avoid network overhead. + +##### CRL Download + +CRL download location (URL) can be obtained from the certificate's CRL Distribution Point (CDP) extension. If the certificate contains multiple CDP locations then each location download is attempted in sequential order. For each CDP location, Notary V2 will try to download the CRL for the default threshold of 10 seconds. If the CRL cannot be downloaded within the timeout threshold the revocation result will be "revocation unavailable". The user may be able to configure this threshold. + +##### Revocation Checking with CRL + +To check the revocation status of a certificate against CRL, the following steps must be performed: + +1. Verify the CRL signature. +1. Verify that the CRL is valid (not expired). A CRL is considered expired if the current date is after the `NextUpdate` field in the CRL. +1. Look up the certificate’s serial number in the CRL. + 1. If the certificate’s serial number is listed in the CRL, look for `InvalidityDate`. If the invalidity date is present and timestamp signature is also present then if the invalidity date is before the timestamping date, the certificate is considered revoked. If the invalidity date is not present in CRL, the certificate is considered revoked. + 1. If the CRL is expired and the certificate is listed in the CRL for any reason other than `certificate hold`, the certificate is considered revoked. + 1. If the certificate is not listed in the CRL or the revocation reason is `certificate hold`, a new CRL is retrieved if the current time is past the time in the `NextUpdate` field in the current CRL. The new CRL is then checked to determine if the certificate is revoked. If the original reason was `certificate hold`, the CRL is checked to determine if the certificate is unrevoked by looking for the `RemoveFromCRL` revocation code. + +##### Revocation Checking with Delta CRLs + +If a delta CRL exists for a base CRL, the `Freshest CRL` extension in the base CRL provides the URL from where the delta CRL can be downloaded. The delta CRLs have their identifying number, plus the "Delta CRL Indicator" extension indicating the version number of the base CRL that must be used with the delta CRL. + +When delta CRLs are implemented, the following results can occur during revocation checking. + +- If the delta CRL cannot be retrieved for some reason, the revocation result will be "revocation unavailable". +- If the delta CRL’s indicator is less than the current base CRL, the revocation result returned will be "revocation unavailable" +- To check revocation of a certificate in Delta CRLs follow steps similar to [Revocation Checking with CRL](#revocation-checking-with-crl). + +#### OCSP + +##### OCSP Download + +OCSP URLs can be obtained from the certificate's authority information access (AIA) extension as defined in [RFC-2560](https://datatracker.ietf.org/doc/html/rfc2560). Notary V2 will wait for a default threshold of 5 seconds to receive an OCSP response. If OCSP response is not available within the timeout threshold the revocation result will be "revocation unavailable". The user may be able to configure this threshold. + +##### Revocation Checking with OCSP + +To check the revocation status of a certificate using OCSP, the following steps must be performed. + +1. Verify the signature of the OCSP response. This step also includes verifying the OSCP response signing certificate is valid and trusted. The OCSP signing certificate must be issued by the same CA as the certificate being verified or the OCSP response must be signed by the issuing CA. +1. Verify that the OCSP response is valid (not expired). A CRL is considered expired if the current date is after the `NextUpdate` field in the CRL. +1. Verify that the OCSP response indicates that the certificate is not revoked i.e `CertStatus` is `good`. + 1. If the certificate is revoked i.e `CertStatus` is `revoked`, look for `InvalidityDate`. If the invalidity date is present and timestamp signature is also present then if the invalidity date is before the timestamping date, the certificate is considered revoked. If the invalidity date is not present in OCSP response, the certificate is considered revoked. +1. If `id-pkix-ocsp-nocheck`(1.3.6.1.5.5.7.48.1.5) extension is not present on the OCSP signing certificate then revocation checking must be performed using CRLs for the OCSP signing certificate. ## FAQ From 90371bf0fc4cfee14b17cbdfa363c80e15b95c86 Mon Sep 17 00:00:00 2001 From: Pritesh Bandi Date: Tue, 1 Feb 2022 21:35:41 -0800 Subject: [PATCH 2/3] Fix defination of fail open and fail close Signed-off-by: Pritesh Bandi --- trust-store-trust-policy-specification.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/trust-store-trust-policy-specification.md b/trust-store-trust-policy-specification.md index eb9fe177..aace376f 100644 --- a/trust-store-trust-policy-specification.md +++ b/trust-store-trust-policy-specification.md @@ -157,8 +157,8 @@ Property descriptions Value descriptions - **`enforce`**: This means implementation MUST perform validation and throw an error if validation fails. -- **`enforceWithFailOpen`**: This means implementation MUST perform validation and if validation fails because the endpoint is not reachable, the implementation MUST throw an error and MUST fail the validation. -- **`enforceWithFailClose`**: This means implementation MUST perform validation and if validation fails because the endpoint is not reachable, the implementation MUST log an error and MUST NOT fail the validation. +- **`enforceWithFailOpen`**: This means implementation MUST perform validation and if validation fails because the endpoint is not reachable, the implementation MUST log an error and MUST NOT fail the validation. +- **`enforceWithFailClose`**: This means implementation MUST perform validation and if validation fails because the endpoint is not reachable, the implementation MUST throw an error and MUST fail the validation. - **`warn`**: This means implementation MUST perform the validation and if validation fails(because of any reason) the implementation MUST log an error and MUST NOT fail validation. - **`skip`**: This means implementation MUST NOT perform the validation. @@ -224,7 +224,7 @@ The implementation must allow the user to execute custom validations. These cust If the certificate revocation trust-store setting is set to `skip`, skip the below steps. Otherwise, check for revocation status for certificate and certificate chain. -1. If the revocation status of any of the certificates cannot be determined (revocation unavailable) and `signingIdentityRevocation` is set to either `enforceWithFailClose` or `warn` then log a warning and skip the below steps. Otherwise, fail the signature validation and exit. +1. If the revocation status of any of the certificates cannot be determined (revocation unavailable) and `signingIdentityRevocation` is set to either `enforceWithFailOpen` or `warn` then log a warning and skip the below steps. Otherwise, fail the signature validation and exit. 1. If any of the certificates are revoked and `signingIdentityRevocation` is set to either `enforceWithFailOpen` or `enforceWithFailClose` then fail signature validation and exit else log a warning. Starting from Root to leaf certificate, for each certificate in the certificate chain, perform the following steps to check its revocation status: From 2ab406b89b078ecefc0a8adb3caaa8fd9ee2a6ed Mon Sep 17 00:00:00 2001 From: Pritesh Bandi Date: Wed, 2 Feb 2022 16:42:29 -0800 Subject: [PATCH 3/3] some more minor changes Signed-off-by: Pritesh Bandi --- signature-specification.md | 18 ++++++++---------- trust-store-trust-policy-specification.md | 2 +- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/signature-specification.md b/signature-specification.md index b466bb36..f4c92637 100644 --- a/signature-specification.md +++ b/signature-specification.md @@ -232,22 +232,20 @@ The signing certificate's public key algorithm and size MUST be used to determin ### Certificate Requirements -The signing certificate MUST meet the following minimum requirements: +The **signing certificate** MUST meet the following minimum requirements: -- The signing certificate MUST satisfy the following constraints: - - The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). - - The extKeyUsage extension MUST be present and its value MUST be id-kp-codeSigning ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). - - If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). +- The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). +- The extKeyUsage extension MUST be present and its value MUST be id-kp-codeSigning ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). +- If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). - The certificate MUST abide by the following key length restrictions: - For RSA public key, the key length MUST be 2048 bits or higher. - For ECDSA public key, the key length MUST be 256 bits or higher. -The timestamping certificate MUST meet the following minimum requirements: +The **timestamping certificate** MUST meet the following minimum requirements: -- The timestamping certificate MUST satisfy the following constraints: - - The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). - - The extKeyUsage extension MUST be present and and MUST be marked critical. The value of extension MUST be id-kp-timeStamping ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). - - If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). +- The keyUsage extension MUST be present and MUST be marked critical. The bit positions for digitalSignature MUST be set ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3)). +- The extKeyUsage extension MUST be present and and MUST be marked critical. The value of extension MUST be id-kp-timeStamping ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12)). +- If the basicConstraints extension is present, the cA field MUST be set false ([RFC-5280](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)). - The certificate MUST abide by the following key length restrictions: - For RSA public key, the key length MUST be 2048 bits or higher. - For ECDSA public key, the key length MUST be 256 bits or higher. diff --git a/trust-store-trust-policy-specification.md b/trust-store-trust-policy-specification.md index aace376f..b268be95 100644 --- a/trust-store-trust-policy-specification.md +++ b/trust-store-trust-policy-specification.md @@ -256,7 +256,7 @@ To check the revocation status of a certificate against CRL, the following steps 1. Verify the CRL signature. 1. Verify that the CRL is valid (not expired). A CRL is considered expired if the current date is after the `NextUpdate` field in the CRL. 1. Look up the certificate’s serial number in the CRL. - 1. If the certificate’s serial number is listed in the CRL, look for `InvalidityDate`. If the invalidity date is present and timestamp signature is also present then if the invalidity date is before the timestamping date, the certificate is considered revoked. If the invalidity date is not present in CRL, the certificate is considered revoked. + 1. If the certificate’s serial number is listed in the CRL, look for `InvalidityDate`. If CRL has invalidity date and artifact signature is timestamped then compare the invalidity date with the timestamping date. If the invalidity date is before the timestamping date, the certificate is considered revoked. If the invalidity date is not present in CRL, the certificate is considered revoked. 1. If the CRL is expired and the certificate is listed in the CRL for any reason other than `certificate hold`, the certificate is considered revoked. 1. If the certificate is not listed in the CRL or the revocation reason is `certificate hold`, a new CRL is retrieved if the current time is past the time in the `NextUpdate` field in the current CRL. The new CRL is then checked to determine if the certificate is revoked. If the original reason was `certificate hold`, the CRL is checked to determine if the certificate is unrevoked by looking for the `RemoveFromCRL` revocation code.