Grafeas V1 Client - Class Signature (1.0.0)

Reference documentation and code samples for the Grafeas V1 Client class Signature.

Verifiers (e.g. Kritis implementations) MUST verify signatures with respect to the trust anchors defined in policy (e.g. a Kritis policy).

Typically this means that the verifier has been configured with a map from public_key_id to public key material (and any required parameters, e.g. signing algorithm). In particular, verification implementations MUST NOT treat the signature public_key_id as anything more than a key lookup hint. The public_key_id DOES NOT validate or authenticate a public key; it only provides a mechanism for quickly selecting a public key ALREADY CONFIGURED on the verifier through a trusted channel. Verification implementations MUST reject signatures in any of the following circumstances:

• The public_key_id is not recognized by the verifier.
• The public key that public_key_id refers to does not verify the signature with respect to the payload. The signature contents SHOULD NOT be "attached" (where the payload is included with the serialized signature bytes). Verifiers MUST ignore any "attached" payload and only verify signatures with respect to explicitly provided payload (e.g. a payload field on the proto message that holds this Signature, or the canonical serialization of the proto message that holds this signature).

Generated from protobuf message grafeas.v1.Signature

Constructor.

The content of the signature, an opaque bytestring.

The payload that this signature verifies MUST be unambiguously provided with the Signature during verification. A wrapper message might provide the payload explicitly. Alternatively, a message might have a canonical serialization that can always be unambiguously computed to derive the payload.

The content of the signature, an opaque bytestring.

The payload that this signature verifies MUST be unambiguously provided with the Signature during verification. A wrapper message might provide the payload explicitly. Alternatively, a message might have a canonical serialization that can always be unambiguously computed to derive the payload.

The identifier for the public key that verifies this signature.

• The public_key_id is required.
  • The public_key_id SHOULD be an RFC3986 conformant URI.
  • When possible, the public_key_id SHOULD be an immutable reference, such as a cryptographic digest. Examples of valid public_key_ids: OpenPGP V4 public key fingerprint:
  • "openpgp4fpr:74FAF3B861BDA0870C7B6DEF607E48D2A663AEEA" See https://www.iana.org/assignments/uri-schemes/prov/openpgp4fpr for more details on this scheme. RFC6920 digest-named SubjectPublicKeyInfo (digest of the DER serialization):
  • "ni:///sha-256;cD9o9Cq6LG3jD0iKXqEi_vdjJGecm_iXkbqVoScViaU"
  • "nih:///sha-256;703f68f42aba2c6de30f488a5ea122fef76324679c9bf89791ba95a1271589a5"

The identifier for the public key that verifies this signature.

• The public_key_id is required.
  • The public_key_id SHOULD be an RFC3986 conformant URI.
  • When possible, the public_key_id SHOULD be an immutable reference, such as a cryptographic digest. Examples of valid public_key_ids: OpenPGP V4 public key fingerprint:
  • "openpgp4fpr:74FAF3B861BDA0870C7B6DEF607E48D2A663AEEA" See https://www.iana.org/assignments/uri-schemes/prov/openpgp4fpr for more details on this scheme. RFC6920 digest-named SubjectPublicKeyInfo (digest of the DER serialization):
  • "ni:///sha-256;cD9o9Cq6LG3jD0iKXqEi_vdjJGecm_iXkbqVoScViaU"
  • "nih:///sha-256;703f68f42aba2c6de30f488a5ea122fef76324679c9bf89791ba95a1271589a5"