Allow X509Chain callers to prevent retrieval of missing certificates

[bartonjs]

Background and Motivation

Callers sometimes want to build a "fully offline" X509Chain, but the only exposed online/offline mode pertains to revocation processing. Alternatively, they may want to be in a "limited online" state, where the only network operations are for retrieving up-to-date CRL/OCSP responses for the end-entity certificate.

Proposed API

namespace System.Security.Cryptography.X509Certificates
{
    public partial class X509ChainPolicy
    {
+        // false (default) for the current behavior,
+        // true to only use the system stores and the ExtraStore and CustomTrust collections.
+        public bool DisableCertificateFetch { get; set; }
    }
}

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[stephentoub]

Would there be any benefit in an enum with all the various places it could get the cert from, rather than a bool that splits them into two categories?

[bartonjs]

If we had a fully managed chain processor on all OSes, sure. But for Windows and macOS we only get a boolean for suppressing certificate downloads. Persistent storage (especially for system root trust) can't really be disabled.

[vcsjones]

@bartonjs I assume the intent of this flag is to disable AIA fetching, or anything that can cause the network to be hit (aside from revocation checking)?

Put another way, on Windows, will this set CERT_CHAIN_DISABLE_AUTH_ROOT_AUTO_UPDATE and CERT_CHAIN_DISABLE_AIA? Both? One?

[bartonjs]

I had only planned on CERT_CHAIN_DISABLE_AIA. CERT_CHAIN_DISABLE_AUTH_ROOT_AUTO_UPDATE is also reasonable; though I feel like that usually doesn't involve a network. But it might, so why not? 😄.

[vcsjones]

though I feel like that usually doesn't involve a network

Isn't this the flag that controls whether or not the cert chain builder will kick off a "try to get intermediate certificates and new roots from Windows Update"?

[bartonjs]

Yeah, but based on some black-box (e.g. yank the network cable) observation 10-15 years ago (could be bad recollection, could have changed since then) I think that the WU bundle ends up just being a background-downloaded bundle and the flag is "ugh, if I need to, crack open the bundle and see if there's anything useful in it". It might have a "I downloaded this too long ago, let's ask live", but there definitely seemed to be a cache, and the side effects that entail from this path being hit.

::shrug::

[bartonjs]

Looks good, but we changed the name:

namespace System.Security.Cryptography.X509Certificates
{
    public partial class X509ChainPolicy
    {
+        // false (default) for the current behavior,
+        // true to only use the system stores and the ExtraStore and CustomTrust collections.
+        public bool DisableCertificateDownloads { get; set; }
    }
}