I'm not sure I understand the comments regarding #2. X509Certificate shouldn't expose that sort of info, and GetDEREncoded is meant to be the "get the DER" approach (and is meant to be as toll-free as possible). So to check issuer name, the 'right' thing is to use the ASN1 utilities with the output from GetDEREncoded and check (with the caveat of delegated OCSP responders)

I guess I wasn't particularly clear on #2. It's not so much a bug, simply a statement of "we're not here yet". The code will have to get an OSCertHandle from the X509Certificate, convert it to DER, and then re-parse the DER using the code in net/cert/internal, in order to extract DER-encoded issuer and public key.

This is essentially just a list of things that, for simplicity, won't be in the initial Expect-Staple CL.

What is the status/goal of the CheckOCSP() code in cert/cert_verify_proc.cc?

Is it only for histogram logging, or was the desire to handle stapled OCSP independently of the underlying CertVerifyProc?

As it stands right now it is a partial implementation which doesn't do any signature verification.

I would like to pull this out and move it to a complete implementation for the built-in verifier.

> Is it only for histogram logging, or was the desire to handle stapled OCSP independently of the underlying CertVerifyProc?

Somewhere in-between; it was for the Expect-Staple reporting experiment: https://docs.google.com/document/d/1aISglJIIwglcOAhqNfK-2vtQl-_dWAapc-VLDh-9-BE/edit

For that use case, the main goal was to help sites uncover cases where responses weren't stapled or were expired, so while David (my intern) intended to implement signature verification, it wasn't high priority and he ran out of time.

I would like to deprecate Expect-Staple (possibly replacing it with a URL-keyed metric) because we don't have bandwidth to maintain/expand it and I think we've learned what we're going to learn from it. So from my perspective you can feel free to do whatever's convenient with that code.

Thanks for the info!

Hi, I'm the (former) intern. My intention was to use the built-in OCSP parsing and verification code that svaldez@ was working on. At the time, the CL with signature verification had not landed yet, and so we skipped it when I was working on Expect-Staple.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dac9751b7e8ec31fc13ec00788f8cbb25aa9580f

commit dac9751b7e8ec31fc13ec00788f8cbb25aa9580f
Author: Eric Roman <eroman@chromium.org>
Date: Thu Sep 21 20:29:42 2017

Add initial OCSP signature checking.

This is based on svaldez's work in https://codereview.chromium.org/1849773002/.

Bug:  649000 , 620005 
Change-Id: I53eca60688eacb3e2b8472532e14af7c0af8e34e
Reviewed-on: https://chromium-review.googlesource.com/676324
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Commit-Queue: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503549}
[modify] https://crrev.com/dac9751b7e8ec31fc13ec00788f8cbb25aa9580f/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/dac9751b7e8ec31fc13ec00788f8cbb25aa9580f/net/cert/internal/ocsp.cc
[modify] https://crrev.com/dac9751b7e8ec31fc13ec00788f8cbb25aa9580f/net/cert/internal/ocsp.h
[modify] https://crrev.com/dac9751b7e8ec31fc13ec00788f8cbb25aa9580f/net/cert/internal/ocsp_unittest.cc

<3