Additional trust anchors in certificate verification

[Michal Petrucha]

Hi everyone,

We need to perform certificate validation against a root certificate that is not part of public trusted root stores. It appears that the additional_trust_anchors argument of CertVerifyProc is just the thing for this task, but the problem is, this API is currently only implemented by the NSS verification backend; all other backends ignore any additional anchors.

My first question is if there is any specific reason why this is the case, other than that nobody cared enough to implement the feature yet. Are there any security implications that inhibit a simple implementation of this API in other backends? Would there be any interest in an implementation, at least for some backends?

A quick search reveals one existing patch implementing the API for Windows [1] – has there been any attempt to incorporate this patch upstream, or is it just that the author didn't submit it for review? (Searching through the BTS and this mailing list didn't turn up anything.)

Furthermore, a few docs on chromium.org seem to imply that some local trust anchors might be actually supported on multiple platforms [2][3]. If that is the case, do these refer to some other mechanism in chromium?

Finally, is there a better way to implement the check than getting the additional_trust_anchors API in place that I'm overlooking?

Thanks,

Michal

[1] https://github.com/nwjs/chromium.src/pull/25/files

[2] http://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

[3] http://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors

[Ryan Sleevi]

Chromium-dev to bcc
+net-dev

On May 28, 2015 8:42 AM, "Michal Petrucha" <mic...@opera.com> wrote:
>
> Hi everyone,
>
> We need to perform certificate validation against a root certificate that is not part of public trusted root stores.

I can stop you right there. This is not something possible to do, safely, and across platforms.

Abandon all hope, ye who enter there.

There is literally no way to do it safely using the OS routines. And I'm including in the considerations the possibility of gross hacks like DLL rewriting trampolines (e.g. like for SHA-256 support on Windows)

> It appears that the additional_trust_anchors argument of CertVerifyProc is just the thing for this task, but the problem is, this API is currently only implemented by the NSS verification backend; all other backends ignore any additional anchors.

Intentional. And it isn't even consistently safe for NSS - just safe enough for the specific use case, ish (enterprise policy pushed certificates)

>
> My first question is if there is any specific reason why this is the case, other than that nobody cared enough to implement the feature yet.

No, it's a common enough request that we're writing our own PKI library to do this (well, that, and we need to do so to transition off NSS)

> Are there any security implications that inhibit a simple implementation of this API in other backends?

Lots. There's lots of hidden caching and global state in the OS libraries such that the parameters of additional trust anchors can bleed into verifications without those additional anchors.

> Would there be any interest in an implementation, at least for some backends?

None. Active opposition :)

>
> A quick search reveals one existing patch implementing the API for Windows [1] – has there been any attempt to incorporate this patch upstream, or is it just that the author didn't submit it for review? (Searching through the BTS and this mailing list didn't turn up anything.)

Not safe, correct, or secure.

>
> Furthermore, a few docs on chromium.org seem to imply that some local trust anchors might be actually supported on multiple platforms [2][3]. If that is the case, do these refer to some other mechanism in chromium?

Different concepts. These refer to distinguishing whether the OS added it or the admin added it (via configuring the OS), not about API level suppliers.

>
> Finally, is there a better way to implement the check than getting the additional_trust_anchors API in place that I'm overlooking?

No clue what you are trying to check. Did I miss it somehow? If it is "verify against a given anchor", no, there is not. Which is to say there are lots of ways, all caveated, and none of which I would steer you towards because all will be broken over time.