Apolitical statement #1: In any large, high-complexity search space where time and resources are limited, you’re just not going to cover the space without using heuristics to guide the search.

Apolitical statement #2: In a nutshell, the heuristic-based search for terrorists is (and was always going to be) problematic because:

• heuristics *always* miss
• heuristics that are good at hitting positives tend to be kind of shitty at missing negatives, and vice versa
• misses on positives (subject X was a terrorist that the search did not identify) and hits on negatives (subject X was misidentified as a terrorist) both really, really suck

There’s a rich an interesting philosophical/political debate to be had over whether we should, as a society, prefer to implement a search that fails in one direction or the other (failing to identify subjects who subsequently harm innocent people, or harming innocent people ourselves).  But that’s not really what I came here to talk about.

I came to say that when we actually get more *information* about what heuristics are likely to work, and what heuristics are unlikely to work, we should (at least temporarily) set aside our positions in the philosophical/political debate to absorb findings that *could* advance the state of the search science.

Link: MI5 released some interesting study results the other day (via CryptoGram).

I was away over the past couple days, failing to get a pre-release (alpha-ish) version of a custom app installed in a customer’s mainframe test environment. The following note represents the most valuable results of around 16 hours of direct professional effort, during which I developed a sore jaw from chewing gum, and our business partner spent about ten grand:

\redacted\-

The following is an overview of the SSL problem, which should provide IBM with enough insight to ‘hit the ground running’ to bring it to resolution.

- - - - - -

We’re trying to initiate a mutually-authenticated SSL session from a z/OS client program to a remote Linux server.

The z/OS system has the client-side certificate / private key ADD’d to the RACF certificate store, as well as the CERTAUTH certificate that was implicitly ADD’ed with auto-generated label ‘LABEL\redecated\’.

In our gsk trace, IRRSDL00 throws an SAF 8, RC 8, REASON 84 error. According to the RACF callable services reference, that indicates:

“The key ring profile for RACF_user_ID/Ring_name or z/OS PKCS #11 token is not found, or the virtual key ring user ID does not exist.”

We’re not trying to use a virtual key ring. We’re trying to explicitly target the keyring and label with the userid/ring-name string and label names in our gsk_* calls to setup and subsequently apply the gsk_environment to the socket we open.

There are two key rings, one for each user we’ve tested with, each of which is CONNECT’ed to BOTH:
1. the client certificate (PERSONAL use)
2. the CERTAUTH root relevant to the client cert

So in each of our tests, the job owner has owned the target key ring. In half of our tests, the job owner does not own the client certificate itself, but in those cases the job owner has UPDATE authority to the LISTRING resource in the FACILITY class.

When we RACLIST all of the profiles that match DIGTRING, we clearly see profiles that appear to map onto the key rings for each user.

For most of the tests, we did NOT have a generic IRR.DIGTCERT.* resource profile, but did have specific ADD, ADDRING, and LISTRING resources defined. When we debugged to the point of discovering IRRSDL00, we found doc indicating that we should define a generic resource, and we did so. We then permitted one of our test users READ authority on the DIGTRING.* generic resource profile, and did a setropts refresh.

There was no change in our program output or the gskssl trace.

Ta daaaaaaa! *takes bow*