diff --git a/gen/jsonschema/schemas/Input.schema.json b/gen/jsonschema/schemas/Input.schema.json index 755f8f24..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. 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 index 240bb0f9..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. 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 index 048185fb..86e12de4 100644 --- a/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go +++ b/gen/pb-go/trustroot/v1/sigstore_trustroot.pb.go @@ -221,10 +221,21 @@ 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. 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. 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..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 @@ -84,11 +84,19 @@ 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. 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. """ 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..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. 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 index 240bb0f9..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. 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 index d3a2dda1..f5d4821c 100644 --- a/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts +++ b/gen/pb-typescript/src/__generated__/sigstore_trustroot.ts @@ -87,10 +87,21 @@ 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. 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. */ export interface TrustedRoot { /** MUST be application/vnd.dev.sigstore.trustedroot+json;version=0.1 */ diff --git a/protos/sigstore_trustroot.proto b/protos/sigstore_trustroot.proto index 39cbaaad..b7a8a9a4 100644 --- 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;