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

Consider changing Workload API CRL field to a map #82

Open
evan2645 opened this issue Jul 16, 2018 · 0 comments
Open

Consider changing Workload API CRL field to a map #82

evan2645 opened this issue Jul 16, 2018 · 0 comments

Comments

@evan2645
Copy link
Member

From @justinburke

Having a map from trust domain to CRL(s) would probably help out client implementors.

As for not checking the signatures of the CRLs: sounds like there would be an implicit contract that server is expected to validate signatures as needed for all of its workloads. Expecting clients not to validate signatures sounds suspect to me... but if that's the intention here, would recommend documenting it.

We discussed possibly skipping signature verification on CRLs during a past SIG-Spec call, but I don't see that the language actually made it into the text. The justification was that data delivered over the Workload API is trusted. To @justinburke's point, while we trust the the control plane has delivered the correct data, we don't get to assert the provenance of the list without validating it.

It is unclear to me exactly which parties are allowed to create/publish CRLs. Traditionally, it is only the authority that the CRL represents. Is there a use case that might require a site administrator to internally distribute a CRL on behalf of a federated authority without having actually received a CRL from them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant