1// Copyright 2018 The Grafeas Authors. All rights reserved.
2//
3// Licensed under the Apache License, Version 2.0 (the "License");
4// you may not use this file except in compliance with the License.
5// You may obtain a copy of the License at
6//
7//    http://www.apache.org/licenses/LICENSE-2.0
8//
9// Unless required by applicable law or agreed to in writing, software
10// distributed under the License is distributed on an "AS IS" BASIS,
11// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12// See the License for the specific language governing permissions and
13// limitations under the License.
14
15syntax = "proto3";
16
17package grafeas.v1beta1.attestation;
18
19import "google/devtools/containeranalysis/v1beta1/common/common.proto";
20
21option go_package = "cloud.google.com/go/containeranalysis/apiv1beta1/containeranalysispb;containeranalysispb";
22option java_multiple_files = true;
23option java_package = "io.grafeas.v1beta1.attestation";
24option objc_class_prefix = "GRA";
25
26// An attestation wrapper with a PGP-compatible signature. This message only
27// supports `ATTACHED` signatures, where the payload that is signed is included
28// alongside the signature itself in the same file.
29message PgpSignedAttestation {
30  // Required. The raw content of the signature, as output by GNU Privacy Guard
31  // (GPG) or equivalent. Since this message only supports attached signatures,
32  // the payload that was signed must be attached. While the signature format
33  // supported is dependent on the verification implementation, currently only
34  // ASCII-armored (`--armor` to gpg), non-clearsigned (`--sign` rather than
35  // `--clearsign` to gpg) are supported. Concretely, `gpg --sign --armor
36  // --output=signature.gpg payload.json` will create the signature content
37  // expected in this field in `signature.gpg` for the `payload.json`
38  // attestation payload.
39  string signature = 1;
40
41  // Type (for example schema) of the attestation payload that was signed.
42  enum ContentType {
43    // `ContentType` is not set.
44    CONTENT_TYPE_UNSPECIFIED = 0;
45    // Atomic format attestation signature. See
46    // https://github.com/containers/image/blob/8a5d2f82a6e3263290c8e0276c3e0f64e77723e7/docs/atomic-signature.md
47    // The payload extracted from `signature` is a JSON blob conforming to the
48    // linked schema.
49    SIMPLE_SIGNING_JSON = 1;
50  }
51
52  // Type (for example schema) of the attestation payload that was signed.
53  // The verifier must ensure that the provided type is one that the verifier
54  // supports, and that the attestation payload is a valid instantiation of that
55  // type (for example by validating a JSON schema).
56  ContentType content_type = 3;
57
58  // This field is used by verifiers to select the public key used to validate
59  // the signature. Note that the policy of the verifier ultimately determines
60  // which public keys verify a signature based on the context of the
61  // verification. There is no guarantee validation will succeed if the
62  // verifier has no key matching this ID, even if it has a key under a
63  // different ID that would verify the signature. Note that this ID should also
64  // be present in the signature content above, but that is not expected to be
65  // used by the verifier.
66  oneof key_id {
67    // The cryptographic fingerprint of the key used to generate the signature,
68    // as output by, e.g. `gpg --list-keys`. This should be the version 4, full
69    // 160-bit fingerprint, expressed as a 40 character hexidecimal string. See
70    // https://tools.ietf.org/html/rfc4880#section-12.2 for details.
71    // Implementations may choose to acknowledge "LONG", "SHORT", or other
72    // abbreviated key IDs, but only the full fingerprint is guaranteed to work.
73    // In gpg, the full fingerprint can be retrieved from the `fpr` field
74    // returned when calling --list-keys with --with-colons.  For example:
75    // ```
76    // gpg --with-colons --with-fingerprint --force-v4-certs \
77    //     --list-keys [email protected]
78    // tru::1:1513631572:0:3:1:5
79    // pub:...<SNIP>...
80    // fpr:::::::::24FF6481B76AC91E66A00AC657A93A81EF3AE6FB:
81    // ```
82    // Above, the fingerprint is `24FF6481B76AC91E66A00AC657A93A81EF3AE6FB`.
83    string pgp_key_id = 2;
84  }
85}
86
87// An attestation wrapper that uses the Grafeas `Signature` message.
88// This attestation must define the `serialized_payload` that the `signatures`
89// verify and any metadata necessary to interpret that plaintext.  The
90// signatures should always be over the `serialized_payload` bytestring.
91message GenericSignedAttestation {
92  // Type of the attestation plaintext that was signed.
93  enum ContentType {
94    // `ContentType` is not set.
95    CONTENT_TYPE_UNSPECIFIED = 0;
96    // Atomic format attestation signature. See
97    // https://github.com/containers/image/blob/8a5d2f82a6e3263290c8e0276c3e0f64e77723e7/docs/atomic-signature.md
98    // The payload extracted in `plaintext` is a JSON blob conforming to the
99    // linked schema.
100    SIMPLE_SIGNING_JSON = 1;
101  }
102
103  // Type (for example schema) of the attestation payload that was signed.
104  // The verifier must ensure that the provided type is one that the verifier
105  // supports, and that the attestation payload is a valid instantiation of that
106  // type (for example by validating a JSON schema).
107  ContentType content_type = 1;
108
109  // The serialized payload that is verified by one or more `signatures`.
110  // The encoding and semantic meaning of this payload must match what is set in
111  // `content_type`.
112  bytes serialized_payload = 2;
113
114  // One or more signatures over `serialized_payload`.  Verifier implementations
115  // should consider this attestation message verified if at least one
116  // `signature` verifies `serialized_payload`.  See `Signature` in common.proto
117  // for more details on signature structure and verification.
118  repeated Signature signatures = 3;
119}
120
121// Note kind that represents a logical attestation "role" or "authority". For
122// example, an organization might have one `Authority` for "QA" and one for
123// "build". This note is intended to act strictly as a grouping mechanism for
124// the attached occurrences (Attestations). This grouping mechanism also
125// provides a security boundary, since IAM ACLs gate the ability for a principle
126// to attach an occurrence to a given note. It also provides a single point of
127// lookup to find all attached attestation occurrences, even if they don't all
128// live in the same project.
129message Authority {
130  // This submessage provides human-readable hints about the purpose of the
131  // authority. Because the name of a note acts as its resource reference, it is
132  // important to disambiguate the canonical name of the Note (which might be a
133  // UUID for security purposes) from "readable" names more suitable for debug
134  // output. Note that these hints should not be used to look up authorities in
135  // security sensitive contexts, such as when looking up attestations to
136  // verify.
137  message Hint {
138    // Required. The human readable name of this attestation authority, for
139    // example "qa".
140    string human_readable_name = 1;
141  }
142
143  // Hint hints at the purpose of the attestation authority.
144  Hint hint = 1;
145}
146
147// Details of an attestation occurrence.
148message Details {
149  // Required. Attestation for the resource.
150  Attestation attestation = 1;
151}
152
153// Occurrence that represents a single "attestation". The authenticity of an
154// attestation can be verified using the attached signature. If the verifier
155// trusts the public key of the signer, then verifying the signature is
156// sufficient to establish trust. In this circumstance, the authority to which
157// this attestation is attached is primarily useful for look-up (how to find
158// this attestation if you already know the authority and artifact to be
159// verified) and intent (which authority was this attestation intended to sign
160// for).
161message Attestation {
162  // Required. The signature, generally over the `resource_url`, that verifies
163  // this attestation. The semantics of the signature veracity are ultimately
164  // determined by the verification engine.
165  oneof signature {
166    // A PGP signed attestation.
167    PgpSignedAttestation pgp_signed_attestation = 1;
168    GenericSignedAttestation generic_signed_attestation = 2;
169  }
170}
171