external data TLS should not depend on caBundle if we can use system verifier

[sozercan]

Describe the solution you'd like
from @enj:

I do not understand why this is a requirement. Normally when making a TLS connection with no pre-configured CA bundle, the system verifier is used (by leaving tls.Config.RootCAs as nil).
open-policy-agent/frameworks#270 (comment)

This is a scenario where a real-signed certs can be used (for example, with Let's Encrypt) and the system verifier can validate

[maxsmythe]

@enj any docs for system verifier?

[enj]

@maxsmythe the x509.Certificate.Verify code is the best way to understand what will happen on different configs based on the OS, the docs are open ended because of the large number of branches:

// If opts.Roots is nil, the platform verifier might be used, and
// verification details might differ from what is described below. If system
// roots are unavailable the returned error will be of type SystemRootsError.

Generally speaking, leaving tls.Config.RootCAs as nil is safe when connecting to a web server unless you have explicit knowledge that the TLS connection needs to use a key from a particular CA (i.e. your browser is not checking that github.com is pinned to some particular CA, just that the platform verifier/system root CAs is happy with it). This is one of the reasons that even distroless images contain the web PKI roots - without them too many things break.

[maxsmythe]

Oh gotcha, I thought "system verifier" was some K8s-specific thing for verifying workloads (similar to Istio).

Sounds like you're saying "use default trusted system certs"

I suppose I don't have anything against using OS-trusted-certs in principle, since root CAs would need to be compromised for it to be risky.

Is there any risk of users finding this behavior unexpected? What behavior does the VWH system have for this?

[enj]

Using system roots by default is what I have traditionally seen, VWHs have that behavior as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[maxsmythe]

still interesting

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.