Consider revisiting X509ChainStatusFlag parsing on macOS

[bartonjs]

The string-matching causes us semi-regular servicing events where we suppress a value that we've previously never seen.

Some thoughts:

• Leave things as is, stay reactionary.
• Reduce the OS question/answer to "build this chain and tell me if it's trusted" (e.g. always send cert.NotBefore as the time for the check).
  • If it fails, run it again without revocation, then try running it with the issuer, keep popping and trying again to build the per-cert data.
  • Figure out other things manually?
    • ExplicitDistrust vs casually untrusted is probably still a problem.
    • Have to see what things like InvalidBasicConstraints to do the questions.
• Map an unknown codes + !success to some existing code, like HasNotSupportedCriticalExtension.
  • This probably isn't a good idea, since it's just a different form of "this worked yesterday, and fails today, and there's nothing you can do about it".
• See if there's a better set of OS functionality we can call, now that the minimum OS version has moved forward significantly since we originally wrote this.
• Decide that (assuming we do) we have positive tests for all existing codes, and we'll react to the string changing (if it does), and that we're OK with the platform doing something like changing "Revocation" to "CertRevoked" means existing applications lose that data with no error reported.
  • We /could/ move some of the unit tests to startup tests; but that's tricky due to expiration and potential network needs.
  • We're probably not OK with this.

The most promising would be if there's better OS functionality we can depend on. Otherwise, we're probably best off with keeping the course. Not understanding a new critical failure would be a really bad state to be in.

[vcsjones]

Perhaps one area of improvement is the diagnostic here:

runtime/src/libraries/System.Security.Cryptography.X509Certificates/src/Internal/Cryptography/Pal.OSX/ChainPal.cs

Lines 297 to 301 in 85aee4d

	if (ret != 0)
	{
	Debug.Fail($"X509ChainGetStatusAtIndex returned unexpected error {ret}");
	throw new CryptographicException();
	}

It isn't very user actionable, but it would make it easier for people and you folks to troubleshoot running in to this. Perhaps we can even get a CFArray of the strings back from the PAL of the strings and include them in the exception.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.