Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add checkpoint key ID to trust root #284

Merged
merged 2 commits into from
Apr 8, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions gen/jsonschema/schemas/Bundle.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -136,7 +136,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down Expand Up @@ -229,7 +229,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
},
"dev.sigstore.rekor.v1.InclusionPromise": {
"properties": {
Expand Down
2 changes: 1 addition & 1 deletion gen/jsonschema/schemas/Checkpoint.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
}
}
}
9 changes: 7 additions & 2 deletions gen/jsonschema/schemas/ClientTrustConfig.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down Expand Up @@ -243,7 +243,12 @@
"logId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The unique identifier for this transparency log."
"description": "The unique identifier for this transparency log. Represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2"
},
"checkpointKeyId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The checkpoint key identifier for the log used in a checkpoint. Optional, not provided for logs that do not generate checkpoints. For logs that do generate checkpoints, if not set, assume log_id equals checkpoint_key_id. Follows the specification described here for ECDSA and Ed25519 signatures: https://github.com/C2SP/C2SP/blob/main/signed-note.md#signatures For RSA signatures, the key ID will match the ECDSA format, the hashed DER-encoded SPKI public key. Publicly witnessed logs MUST NOT use RSA-signed checkpoints, since witnesses do not support RSA signatures. This is provided for convenience. Clients can also calculate the checkpoint key ID given the log's public key. SHOULD be set for logs generating Ed25519 signatures. SHOULD be 4 bytes long, as a truncated hash."
}
},
"additionalProperties": false,
Expand Down
2 changes: 1 addition & 1 deletion gen/jsonschema/schemas/InclusionProof.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
}
}
}
11 changes: 8 additions & 3 deletions gen/jsonschema/schemas/Input.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -182,7 +182,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down Expand Up @@ -422,7 +422,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
},
"dev.sigstore.rekor.v1.InclusionPromise": {
"properties": {
Expand Down Expand Up @@ -585,7 +585,12 @@
"logId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The unique identifier for this transparency log."
"description": "The unique identifier for this transparency log. Represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2"
},
"checkpointKeyId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The checkpoint key identifier for the log used in a checkpoint. Optional, not provided for logs that do not generate checkpoints. For logs that do generate checkpoints, if not set, assume log_id equals checkpoint_key_id. Follows the specification described here for ECDSA and Ed25519 signatures: https://github.com/C2SP/C2SP/blob/main/signed-note.md#signatures For RSA signatures, the key ID will match the ECDSA format, the hashed DER-encoded SPKI public key. Publicly witnessed logs MUST NOT use RSA-signed checkpoints, since witnesses do not support RSA signatures. This is provided for convenience. Clients can also calculate the checkpoint key ID given the log's public key. SHOULD be set for logs generating Ed25519 signatures. SHOULD be 4 bytes long, as a truncated hash."
}
},
"additionalProperties": false,
Expand Down
2 changes: 1 addition & 1 deletion gen/jsonschema/schemas/LogId.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down
4 changes: 2 additions & 2 deletions gen/jsonschema/schemas/TransparencyLogEntry.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand All @@ -67,7 +67,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
},
"dev.sigstore.rekor.v1.InclusionPromise": {
"properties": {
Expand Down
9 changes: 7 additions & 2 deletions gen/jsonschema/schemas/TransparencyLogInstance.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,12 @@
"logId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The unique identifier for this transparency log."
"description": "The unique identifier for this transparency log. Represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2"
},
"checkpointKeyId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The checkpoint key identifier for the log used in a checkpoint. Optional, not provided for logs that do not generate checkpoints. For logs that do generate checkpoints, if not set, assume log_id equals checkpoint_key_id. Follows the specification described here for ECDSA and Ed25519 signatures: https://github.com/C2SP/C2SP/blob/main/signed-note.md#signatures For RSA signatures, the key ID will match the ECDSA format, the hashed DER-encoded SPKI public key. Publicly witnessed logs MUST NOT use RSA-signed checkpoints, since witnesses do not support RSA signatures. This is provided for convenience. Clients can also calculate the checkpoint key ID given the log's public key. SHOULD be set for logs generating Ed25519 signatures. SHOULD be 4 bytes long, as a truncated hash."
}
},
"additionalProperties": false,
Expand All @@ -41,7 +46,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down
9 changes: 7 additions & 2 deletions gen/jsonschema/schemas/TrustedRoot.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down Expand Up @@ -235,7 +235,12 @@
"logId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The unique identifier for this transparency log."
"description": "The unique identifier for this transparency log. Represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2"
},
"checkpointKeyId": {
"$ref": "#/definitions/dev.sigstore.common.v1.LogId",
"additionalProperties": false,
"description": "The checkpoint key identifier for the log used in a checkpoint. Optional, not provided for logs that do not generate checkpoints. For logs that do generate checkpoints, if not set, assume log_id equals checkpoint_key_id. Follows the specification described here for ECDSA and Ed25519 signatures: https://github.com/C2SP/C2SP/blob/main/signed-note.md#signatures For RSA signatures, the key ID will match the ECDSA format, the hashed DER-encoded SPKI public key. Publicly witnessed logs MUST NOT use RSA-signed checkpoints, since witnesses do not support RSA signatures. This is provided for convenience. Clients can also calculate the checkpoint key ID given the log's public key. SHOULD be set for logs generating Ed25519 signatures. SHOULD be 4 bytes long, as a truncated hash."
}
},
"additionalProperties": false,
Expand Down
4 changes: 2 additions & 2 deletions gen/jsonschema/schemas/VerificationMaterial.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@
"properties": {
"keyId": {
"type": "string",
"description": "The unique id of the log, represented as the SHA-256 hash of the log's public key, calculated over the DER encoding of the key represented as SubjectPublicKeyInfo. See https://www.rfc-editor.org/rfc/rfc6962#section-3.2",
"description": "The unique identity of the log, represented by its public key.",
"format": "binary",
"binaryEncoding": "base64"
}
Expand Down Expand Up @@ -146,7 +146,7 @@
"additionalProperties": false,
"type": "object",
"title": "Checkpoint",
"description": "The checkpoint MUST contain a signature of the tree head (root hash), size of the tree and the transparency log's unique identifier (log ID). It MAY also be followed by any optional data. The result is a string, the format is described here https://github.com/transparency-dev/formats/blob/main/log/README.md The details are here https://github.com/sigstore/rekor/blob/a6e58f72b6b18cc06cefe61808efd562b9726330/pkg/util/signed_note.go#L114 The signature has the same format as InclusionPromise.signed_entry_timestamp. See below for more details."
"description": "The checkpoint MUST contain an origin string as a unique log identifier, the tree size, and the root hash. It MAY also be followed by optional data, and clients MUST NOT assume optional data. The checkpoint MUST also contain a signature over the root hash (tree head). The checkpoint MAY contain additional signatures, but the first SHOULD be the signature from the log. Checkpoint contents are concatenated with newlines into a single string. The checkpoint format is described in https://github.com/transparency-dev/formats/blob/main/log/README.md and https://github.com/C2SP/C2SP/blob/main/tlog-checkpoint.md. An example implementation can be found in https://github.com/sigstore/rekor/blob/main/pkg/util/signed_note.go"
},
"dev.sigstore.rekor.v1.InclusionPromise": {
"properties": {
Expand Down
Loading