Clarified how clients should work with the trust root during rotations (

#210) * Clarified how clients should work with the trust root during rotations Signed-off-by: Fredrik Skogman <[email protected]> * generated client bindings Signed-off-by: Fredrik Skogman <[email protected]> * add section on overlapping intervals Signed-off-by: Fredrik Skogman <[email protected]> --------- Signed-off-by: Fredrik Skogman <[email protected]>
sigstore · Feb 2, 2024 · 0440eff · 0440eff
1 parent 0d87737
commit 0440eff
Show file tree

Hide file tree

Showing 8 changed files with 59 additions and 18 deletions.
diff --git a/gen/jsonschema/schemas/Input.schema.json b/gen/jsonschema/schemas/Input.schema.json
@@ -630,7 +630,7 @@
             "additionalProperties": false,
             "type": "object",
             "title": "Trusted Root",
-            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. The currently used instances MUST NOT have their 'end' timestamp set in their 'valid_for' attribute for easy identification. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first and the current instance last."
+            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first. Only the last instance is allowed to have their 'end' timestamp unset. All previous instances MUST have a closed interval of validity. The last instance MAY have a closed interval. Clients MUST accept instances that overlaps in time, if not clients may experience problems during rotations of verification materials. To be able to manage planned rotations of either transparency logs or certificate authorities, clienst MUST accept lists of instances where the last instance have a 'valid_for' that belongs to the future. This should not be a problem as clients SHOULD first seek the trust root for a suitable instance before creating a per artifact trust root (that is, a sub-set of the complete trust root) that is used for verification."
         },
         "dev.sigstore.verification.v1.Artifact": {
             "properties": {

diff --git a/gen/jsonschema/schemas/TrustedRoot.schema.json b/gen/jsonschema/schemas/TrustedRoot.schema.json
@@ -44,7 +44,7 @@
             "additionalProperties": false,
             "type": "object",
             "title": "Trusted Root",
-            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. The currently used instances MUST NOT have their 'end' timestamp set in their 'valid_for' attribute for easy identification. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first and the current instance last."
+            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first. Only the last instance is allowed to have their 'end' timestamp unset. All previous instances MUST have a closed interval of validity. The last instance MAY have a closed interval. Clients MUST accept instances that overlaps in time, if not clients may experience problems during rotations of verification materials. To be able to manage planned rotations of either transparency logs or certificate authorities, clienst MUST accept lists of instances where the last instance have a 'valid_for' that belongs to the future. This should not be a problem as clients SHOULD first seek the trust root for a suitable instance before creating a per artifact trust root (that is, a sub-set of the complete trust root) that is used for verification."
         },
         "dev.sigstore.common.v1.DistinguishedName": {
             "properties": {

diff --git a/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go b/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go
diff --git a/gen/pb-python/sigstore_protobuf_specs/dev/sigstore/trustroot/v1/__init__.py b/gen/pb-python/sigstore_protobuf_specs/dev/sigstore/trustroot/v1/__init__.py
diff --git a/gen/pb-rust/schemas/Input.schema.json b/gen/pb-rust/schemas/Input.schema.json
@@ -630,7 +630,7 @@
             "additionalProperties": false,
             "type": "object",
             "title": "Trusted Root",
-            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. The currently used instances MUST NOT have their 'end' timestamp set in their 'valid_for' attribute for easy identification. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first and the current instance last."
+            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first. Only the last instance is allowed to have their 'end' timestamp unset. All previous instances MUST have a closed interval of validity. The last instance MAY have a closed interval. Clients MUST accept instances that overlaps in time, if not clients may experience problems during rotations of verification materials. To be able to manage planned rotations of either transparency logs or certificate authorities, clienst MUST accept lists of instances where the last instance have a 'valid_for' that belongs to the future. This should not be a problem as clients SHOULD first seek the trust root for a suitable instance before creating a per artifact trust root (that is, a sub-set of the complete trust root) that is used for verification."
         },
         "dev.sigstore.verification.v1.Artifact": {
             "properties": {

diff --git a/gen/pb-rust/schemas/TrustedRoot.schema.json b/gen/pb-rust/schemas/TrustedRoot.schema.json
@@ -44,7 +44,7 @@
             "additionalProperties": false,
             "type": "object",
             "title": "Trusted Root",
-            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. The currently used instances MUST NOT have their 'end' timestamp set in their 'valid_for' attribute for easy identification. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first and the current instance last."
+            "description": "TrustedRoot describes the client's complete set of trusted entities. How the TrustedRoot is populated is not specified, but can be a combination of many sources such as TUF repositories, files on disk etc. The TrustedRoot is not meant to be used for any artifact verification, only to capture the complete/global set of trusted verification materials. When verifying an artifact, based on the artifact and policies, a selection of keys/authorities are expected to be extracted and provided to the verification function. This way the set of keys/authorities can be kept to a minimal set by the policy to gain better control over what signatures that are allowed. The embedded transparency logs, CT logs, CAs and TSAs MUST include any previously used instance -- otherwise signatures made in the past cannot be verified. All the listed instances SHOULD be sorted by the 'valid_for' in ascending order, that is, the oldest instance first. Only the last instance is allowed to have their 'end' timestamp unset. All previous instances MUST have a closed interval of validity. The last instance MAY have a closed interval. Clients MUST accept instances that overlaps in time, if not clients may experience problems during rotations of verification materials. To be able to manage planned rotations of either transparency logs or certificate authorities, clienst MUST accept lists of instances where the last instance have a 'valid_for' that belongs to the future. This should not be a problem as clients SHOULD first seek the trust root for a suitable instance before creating a per artifact trust root (that is, a sub-set of the complete trust root) that is used for verification."
         },
         "dev.sigstore.common.v1.DistinguishedName": {
             "properties": {

diff --git a/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts b/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts
diff --git a/protos/sigstore_trustroot.proto b/protos/sigstore_trustroot.proto
@@ -81,10 +81,21 @@ message CertificateAuthority {
 // The embedded transparency logs, CT logs, CAs and TSAs MUST include any
 // previously used instance -- otherwise signatures made in the past cannot
 // be verified.
-// The currently used instances MUST NOT have their 'end' timestamp set in
-// their 'valid_for' attribute for easy identification.
+//
 // All the listed instances SHOULD be sorted by the 'valid_for' in ascending
-// order, that is, the oldest instance first and the current instance last.
+// order, that is, the oldest instance first. Only the last instance is
+// allowed to have their 'end' timestamp unset. All previous instances MUST
+// have a closed interval of validity. The last instance MAY have a closed
+// interval. Clients MUST accept instances that overlaps in time, if not
+// clients may experience problems during rotations of verification
+// materials.
+//
+// To be able to manage planned rotations of either transparency logs or
+// certificate authorities, clienst MUST accept lists of instances where
+// the last instance have a 'valid_for' that belongs to the future.
+// This should not be a problem as clients SHOULD first seek the trust root
+// for a suitable instance before creating a per artifact trust root (that
+// is, a sub-set of the complete trust root) that is used for verification.
 message TrustedRoot {
         // MUST be application/vnd.dev.sigstore.trustedroot+json;version=0.1
         string media_type = 1;