gpgsm OCSP question (key usage checking for response verification)

[Werner Koch]

On Thu, 18 May 2006 09:55, Daiki Ueno said:

> I think that use == 0xfffffff is valid condition, so I would like to
> know why use != ~0 is necessary here.

The reason I implemented it this way is due RFC2560:

  2.6 OCSP Signature Authority Delegation

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

What I missed is that this requirement for an extendedKeyUsage is only
for delegated OCSP signers.  4.2.2.2 describes the requirements in
more details.  Notice also this comment in certlist.c:

              /* This is a hack to cope with OCSP.  Note that we do
                 not yet fully comply with the requirements and that
                 the entire CRL/OCSP checking thing should undergo a
                 thorough review and probably redesign. */
              if ( !strcmp (p, oid_kp_ocspSigning))
                have_ocsp_signing = 1;

The whole callback thing for OCSP signing is a hack anyway to help
dirmngr.  It is the wrong approach.  nstead dirmngr should be
self-contained and validate the OCSP response on his own.  I once
tried to avoid this but it later turned out that we need to have
validation code anyway in dirmngr and thus the plan is to remove this
OCSP stuff from gpgsm and implement it only in dirmngr.  Yes, this is
shifting problems :-).

Meanwhile the vaildation code for CRLs in dirmngr is pretty stable and
thenext task will be to finalize Dirmngr's OCSP checking.  There is
also one other thing to do in libksba: Checking the nonce of the
response needs to be implemented.  After this has been implemented I
will do an dirmngr 1.0.  A lot of work is still waiting to be able to
release gnupg 2.0 as well as a final dirmngr this summer.


Shalom-Salam,

   Werner