(In reply to Ryan Sleevi from comment #3)
Gotcha! Yeah, you definitely want to keep
CERT_CreateSubjectCertList for the fallback path, since the preloading isn't going to cover all the cases of the existing Web PKI. A notable carveout in the policy is with respect to technically-constrained sub-CAs, which, for example, AT&T makes use of for their wifi captive portal solution. The other concern was that bypassing the trust domain has the affect of bypassing the 'temp' cert store (the in-memory one), which we don't really have any APIs that do that (the PK11_ methods today largely deal in keys).
Right - another change I'm intending to make is to include any intermediates from the TLS handshake on this fast path, which should work for technically-constrained hierarchies (assuming the server is configured to actually send the right certificates).
I do worry, though, about an API exposing raw CK_OBJECT_HANDLE for certificates, since the NSS API tries to only deal in CERTCertificates for those, and those have to go through the STAN_ layer to be minted (since they hang with the TrustDomain).
Would it help to roll these two into one more focused API like:
SECStatus PK11_FindRawCertsWithSubject(PK11SlotInfo *slot, SECItem *derSubject, PLArenaPool *arena, SECItem **results);
... that would take a particular slot to search for certificates matching a particular subject and return the raw bytes of each?
The 'intent' of the NSS API had been that the
CERTCertDBHandle would encapsulate the 'which slots to search', but I suspect that would still be affected by the
STAN_GetDefaultCryptoContext (which was the transition API to handle the legacy 'global' behaviour of NSS) call within
CERT_CreateSubjectCertList. That's the other part of why I asked - because exposing the PK11_ side adds another nail in the coffin of the CERTCertDBHandle (which we only ever expose a default one).
That would be great if it worked, but this part of NSS has been in this halfway state since before my first internship at Mozilla 10 years ago.
Wouldn't this also run into issues for something like p11kit (on Fedora/RHEL), which replaces the builtin root module with its own (and has several), which functionally look and behave similarly to the softoken DBs. Or is the idea that it would always hit the slow-path if NSS itself hadn't loaded
Yes - the idea is to only use this on
Apologies if it comes off like I'm criticizing the design - just that the NSS public API has tried to limit the exposure directly of PKCS#11, and tended to layer things on (the
PKCS#11 object ->
CERTCertificate layer cake), so exposing something this low-level is super-powerful, and also super-error prone (in terms of object lifetime management), but also an API that would likely quickly become used and impossible to replace or refactor later.
I agree we shouldn't make it easy for consumers of NSS get themselves in a broken state by directly accessing PKCS#11.