Sync guard GatewayCanParseSubject fails to block CN ending in odd-count trailing backslash (1.3.3)

[spbsoluble]

Superseded by #30 (re-filed clean). See #30 and PR #31.

[spbsoluble]

Mechanism correction (verified empirically) + fix

While implementing the fix I probed the actual .NET / BouncyCastle behavior on BouncyCastle.Cryptography 2.0.0 (the plugin's version). Two details in the original writeup are inaccurate, though the net effect and the trigger shape are unchanged:

1. .NET does not double the backslash. X509Certificate2.Subject for a CN ending in one literal backslash returns CN=shape1.lab.test\ — a single, verbatim backslash (…74 00 5C 00). .NET renders literal backslash bytes as-is and quotes separator-bearing values (a,b → CN="a,b") rather than backslash-escaping them. The escape-doubling observed in [Certificates].[IssuedSubject] (5C 00 5C 00) is done by the gateway's store step, not by .NET.

2. new X509Name(true, "CN=x\") does not throw in this BouncyCastle version — nor do "CN=x\\", "CN=x\\\\". Only genuinely malformed strings like a bare unescaped comma ("CN=a,b") throw. So the 1.3.3 guard's mirror op (new X509Name(true, netCert.Subject)) cannot catch the backslash shapes — which is precisely why it admitted them.

Actual trigger (confirmed): the gateway stores the subject with backslashes escape-doubled, then un-escapes one level and re-parses on the search response. A value whose literal-backslash run has odd length collapses to a dangling/unbalanced escape (CN=…\) that the gateway's X509NameTokenizer rejects. Even-length runs round-trip cleanly — which is exactly why the lab repro saw only shape1 (one backslash) abort while shape2 (two) and shape3 (four) synced fine.

Fix

Rather than mirror a specific BouncyCastle call (fragile — the throw lives in the gateway's BouncyCastle build and our local one is more lenient), the guard now checks the shape structurally: reject any subject with an odd-length run of literal backslash bytes, plus keep a defensive local X509Name parse as a second net. Version-independent and matches the observed abort/no-abort split exactly.

Fix on branch fix/issue-28-subject-guard-backslash (off tag 1.3.3): reworked GatewayCanParseSubject + new internal SubjectSurvivesGatewayRoundTrip / HasOddBackslashRun in GCPCAS/Client/GCPCASClient.cs, with pure unit regression tests in GCPCAS.Tests/SubjectGuardTests.cs (run under plain dotnet test; no GCP needed). Targeted 1.3.4 in CHANGELOG.

[spbsoluble]

Superseded by #30 (re-filed). See #30 and PR #31.