compliance: certification program #590
Conversation
- adds `spec/v1.0/certification.md` to document the process and tiers that define trust - adds `spec/v1.0/certification-registry.md` to hold self-certifications - adds `_data/spec_v1-0/certification-registry.yml` to hold a machine readable format for builder self-certifications
SecKatie
requested review from
MarkLodato,
mlieberman85 and
joshuagl
as code owners
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
SecKatie
changed the title
docs/spec/v1.0/certification.md
Outdated
| **[TODO] provide link to questionnaire** | ||
| 2. The build system owner attests to the accuracy of the questionnaire responses | ||
| and publishes it on their website. | ||
| 3. The build system owner publishes their public key to a public key server. |
There was a problem hiding this comment.
the key should be stored in a versioning system?
There was a problem hiding this comment.
Would it make any sense for the SLSA.dev website to accept these attestations and keys in this repository for storage + reference? (Maybe instruct the build system owner to include it in the PR mentioned below in step 4?)
There was a problem hiding this comment.
should ask. Will the collection of metadata require versioning? Will main be the ground truth or will folks cut release every X months to release? (have to be careful how this plays with revocation)
There was a problem hiding this comment.
What do you think of the ideas stated here around keys: #590 (comment) #590 (comment)
Do you think that either of these options would help to satisfy the need for immutable data but also revocation? I hate the idea of a build system owner having to come to our repo and update the version of their key if it get's revoked or expires. It seems like it is a process that is highly vulnerable to human error.
There was a problem hiding this comment.
PKI is definitely better since it pushes the problem to a CA instead of us. One thing to think about, though, is verification. PKI was built for "online" verification, where the client wants to verify that the cert is valid at the time of the connection.
Provenance verification happens "offline", ie a client wants to verify that the provenance was signed at a time where the certificate (and the builder attestation) was valid. This requires to have a log of "time of a signature" like Rekor provides. If you want to support key rotation, you need this feature or a client would always reject provenance signed with a certificate that is expired at verification time.
There was a problem hiding this comment.
I must admit that I don't understand certificate transparency all that well. It would help prove a certificate hadn't expired at the time of signature but not whether the certificate had been revoked, right? IIUC, Sigstore uses very short-lived certificates by design, so revocation isn't part of the design, so even if we require CT for the build system PKI we need a way of handling revocation. Is that right? Or could we just punt revocation to the CAs in the case where builders don't use Sigstore?
There was a problem hiding this comment.
CT in general just stores certs, not time of signatures: this works fine for web PKI / TLS (including key rotation), because verification happens "online". Rekor does store time of signatures, which enables "offline" revocation + key rotation (ephemeral keys are just short-lived rotated keys).
You're correct that Sigstore does not support revocation today, I think there are efforts to build some mechanism "on top" of Sigstore.
|
|
||
| - [ ] Add a link to the SLSA Self-Certification Questionnaire. | ||
|
|
||
| This page lists build systems that have certified conformance to the |
There was a problem hiding this comment.
I think you mentioned we should replace the word conformance with compliance in the spec meeting today
There was a problem hiding this comment.
Although the two terms conformance and compliance are often used interchangeably the right term to use is conformance (along with conformant).
I suggest use this consistently throughout our documentation.
https://wikidiff.com/conformant/compliant for instance states that:
the difference between compliant and conformant is that compliant is willing to comply; [...] while conformant is in accordance with a set of specifications.
|
I don't think the registry should be stored along with the specification. Running a certification program requires quite a bit of infrastructure and people dedicated to the task. I don't think it is practical to have PRs related to registry updates mixed in with specification work. We ought to have a separate repo for the certification program that holds the registry, with its own set of maintainers, against which PRs related to applications can be submitted. This means that certification entries ought to specify which version of SLSA it relates to, in addition to the specific version of the product/offering. |
We should remove the registry in preperation to move it to a dedicated repository.
SecKatie
force-pushed
the
certification-program
branch
from
4453e6f
to
7951939
Compare
SecKatie
changed the title
docs/spec/v1.0/certification.md
Outdated
| **[TODO] provide link to questionnaire** | ||
| 2. The build system owner attests to the accuracy of the questionnaire responses | ||
| and publishes it on their website. | ||
| 3. The build system owner publishes their public key to a public key server. |
There was a problem hiding this comment.
We should have a way to support build systems that use multiple keys.
Two ideas come to mind: either supporting multiple public keys per certification or switching to x509 certs and treating all certs that chains up to the one in the registry as being from the same builder. I suspect the x509 option is over engineered for the moment, but it makes it easier for build systems to add new worker nodes without reusing keys. WYDT?
There was a problem hiding this comment.
I think using x509 certs is the cleanest option (from a user perspective) but it is definitely more difficult from an implementation perspective.
I would love to be able to point to a "root CA" for lack of a better term that each build service owner maintains.
There was a problem hiding this comment.
Yes, that's exactly the model I had in mind. Each build service (or maybe build service type if an owner operates more than one) is the root CA, and they mint certs for each worker they spin up. The problem is that it feels unreasonable to ask a build system operator also to run a CA, or at least it limits the PKI option to organizations of a certain size. That's why we should also have a keyless option with Sigstore.
docs/spec/v1.0/certification.md
Outdated
| 2. The build system owner attests to the accuracy of the questionnaire responses | ||
| and publishes it on their website. | ||
| 3. The build system owner publishes their public key to a public key server. | ||
| 4. The build system owner submits a pull request to add their build system to |
There was a problem hiding this comment.
The registry should also support keyless provenance signing with Sigstore. I think the OIDC issuer + Subject Alternate Name should be enough to identify a builder.
There was a problem hiding this comment.
^ that is a great idea! Do you think that this would scale better than the x509 idea?
Should we standardize on one or offer both as options?
There was a problem hiding this comment.
Sigstore is a CA (Fulcio) using x509 certs for users. It's basically an "instantiation" of the idea
There was a problem hiding this comment.
We should support both Sigstore and more conventional PKI. Sigstore is easier to use, but I don't like the idea of forcing SLSA builders to use Sigstore.
There was a problem hiding this comment.
I think that's a fair point- maybe its to the extent that we recommend Sigstore and show how to do the steps- but also allow/support other options as well.
|
Given the age of this PR, it appears that this effort has stalled. I'm closing this PR to keep the list of open PRs clean. If this gets picked up, we can reopen or create a new PR. |
spec/v1.0/certification.mdto document the process and tiers that define trustspec/v1.0/certification-registry.mdto hold self-certifications_data/spec_v1-0/certification-registry.ymlto hold a machine readable format for builder self-certificationsAddresses #515