From 021ff74ea77d60f7a69fe4a4156fbff33965a822 Mon Sep 17 00:00:00 2001 From: Fredrik Skogman Date: Thu, 1 Feb 2024 12:54:14 +0100 Subject: [PATCH 1/3] Clarified how clients should work with the trust root during rotations Signed-off-by: Fredrik Skogman --- protos/sigstore_trustroot.proto | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/protos/sigstore_trustroot.proto b/protos/sigstore_trustroot.proto index 39cbaaad..c13915bd 100644 --- a/protos/sigstore_trustroot.proto +++ b/protos/sigstore_trustroot.proto @@ -81,10 +81,19 @@ 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. +// +// 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; From a3c1cb9421c70b5bffbbd2362e9a841e4c2fbf91 Mon Sep 17 00:00:00 2001 From: Fredrik Skogman Date: Thu, 1 Feb 2024 13:00:56 +0100 Subject: [PATCH 2/3] generated client bindings Signed-off-by: Fredrik Skogman --- gen/jsonschema/schemas/Input.schema.json | 2 +- gen/jsonschema/schemas/TrustedRoot.schema.json | 2 +- gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go | 15 ++++++++++++--- .../dev/sigstore/trustroot/v1/__init__.py | 16 +++++++++++----- gen/pb-rust/schemas/Input.schema.json | 2 +- gen/pb-rust/schemas/TrustedRoot.schema.json | 2 +- .../src/__generated__/sigstore_trustroot.ts | 15 ++++++++++++--- 7 files changed, 39 insertions(+), 15 deletions(-) diff --git a/gen/jsonschema/schemas/Input.schema.json b/gen/jsonschema/schemas/Input.schema.json index 755f8f24..10ba7a79 100644 --- a/gen/jsonschema/schemas/Input.schema.json +++ b/gen/jsonschema/schemas/Input.schema.json @@ -624,7 +624,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. 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 index 240bb0f9..97b0553a 100644 --- 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. 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 index 048185fb..cbcdd38c 100644 --- a/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go +++ b/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go @@ -221,10 +221,19 @@ func (x *CertificateAuthority) GetValidFor() *v1.TimeRange { // 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. +// +// 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. type TrustedRoot struct { state protoimpl.MessageState sizeCache protoimpl.SizeCache 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 index 6ac2f2fd..a71d10db 100644 --- 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 @@ -84,11 +84,17 @@ class TrustedRoot(betterproto.Message): 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. + 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. 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. """ media_type: str = betterproto.string_field(1) diff --git a/gen/pb-rust/schemas/Input.schema.json b/gen/pb-rust/schemas/Input.schema.json index 755f8f24..10ba7a79 100644 --- a/gen/pb-rust/schemas/Input.schema.json +++ b/gen/pb-rust/schemas/Input.schema.json @@ -624,7 +624,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. 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 index 240bb0f9..97b0553a 100644 --- 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. 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 index d3a2dda1..e054bddf 100644 --- a/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts +++ b/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts @@ -87,10 +87,19 @@ export interface 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. + * + * 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. */ export interface TrustedRoot { /** MUST be application/vnd.dev.sigstore.trustedroot+json;version=0.1 */ From b9f68c48113284b5761529509c3095e4f0590e40 Mon Sep 17 00:00:00 2001 From: Fredrik Skogman Date: Fri, 2 Feb 2024 08:03:28 +0100 Subject: [PATCH 3/3] add section on overlapping intervals Signed-off-by: Fredrik Skogman --- gen/jsonschema/schemas/Input.schema.json | 2 +- gen/jsonschema/schemas/TrustedRoot.schema.json | 2 +- gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go | 4 +++- .../dev/sigstore/trustroot/v1/__init__.py | 14 ++++++++------ gen/pb-rust/schemas/Input.schema.json | 2 +- gen/pb-rust/schemas/TrustedRoot.schema.json | 2 +- .../src/__generated__/sigstore_trustroot.ts | 4 +++- protos/sigstore_trustroot.proto | 4 +++- 8 files changed, 21 insertions(+), 13 deletions(-) diff --git a/gen/jsonschema/schemas/Input.schema.json b/gen/jsonschema/schemas/Input.schema.json index 10ba7a79..b638f36e 100644 --- a/gen/jsonschema/schemas/Input.schema.json +++ b/gen/jsonschema/schemas/Input.schema.json @@ -624,7 +624,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. 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. 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." + "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 index 97b0553a..b9583858 100644 --- 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. 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. 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." + "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 index cbcdd38c..86e12de4 100644 --- a/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go +++ b/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go @@ -226,7 +226,9 @@ func (x *CertificateAuthority) GetValidFor() *v1.TimeRange { // 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. +// 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 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 index a71d10db..63b3e85d 100644 --- 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 @@ -88,12 +88,14 @@ class TrustedRoot(betterproto.Message): 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. 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 + 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. """ diff --git a/gen/pb-rust/schemas/Input.schema.json b/gen/pb-rust/schemas/Input.schema.json index 10ba7a79..b638f36e 100644 --- a/gen/pb-rust/schemas/Input.schema.json +++ b/gen/pb-rust/schemas/Input.schema.json @@ -624,7 +624,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. 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. 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." + "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 index 97b0553a..b9583858 100644 --- 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. 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. 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." + "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 index e054bddf..f5d4821c 100644 --- a/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts +++ b/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts @@ -92,7 +92,9 @@ export interface CertificateAuthority { * 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. + * 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 diff --git a/protos/sigstore_trustroot.proto b/protos/sigstore_trustroot.proto index c13915bd..b7a8a9a4 100644 --- a/protos/sigstore_trustroot.proto +++ b/protos/sigstore_trustroot.proto @@ -86,7 +86,9 @@ message CertificateAuthority { // 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. +// 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