You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
From @justinburke
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?
The text was updated successfully, but these errors were encountered: