Re: Validating OCSP response signatures

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Do we consider failing (by policy) to validate the signature of OCSP responses
> to be a vulnerability? I did nudge SMC on Twitter but he was reticent to give
> a definitive view? Affects open and closed source code bases.

We're not sure that the MITRE CVE team can provide a useful answer unless
the question is made more specific.

Do you mean something like:

  The product's documentation states that it is fully compliant with
  RFC 2560 including "3.2 ... Prior to accepting a signed response as
  valid, OCSP clients SHALL confirm that: ... 2. The signature on the
  response is valid."

  There is a comment in the source code such as:
  /* by policy, we do not validate the signature */

  Also, the actual implementation does not validate the signature.

? This type of issue could typically have a CVE ID for something like
"misleads users about whether a security feature is offered."

Or, do you mean that the product's documentation doesn't claim full
RFC 2560 compliance, and signatures aren't validated for a reason such as:

  - the vendor feels that online revocation checking, for certificates
    of web sites, is a fundamentally flawed idea and does not want to
    bother writing any code (such as the signature-validation part) to
    support that

  - the vendor feels that online revocation checking, for certificates
    of web sites, is a fundamentally flawed idea and has disabled
    their already-written code in a political/advocacy move to try
    to discourage use of OCSP

  - the vendor feels that validation loops are a more relevant threat
    than bad signatures

  - the vendor is willing to accept the risk of bad signatures
    because they feel it's important to accept information about
    a revocation whenever that information is even possibly valid
    
? These would not have CVE IDs. If "by policy" means "for an unknown
policy reason" then we feel that there probably wouldn't be a CVE ID.
Vendors that don't want to develop or maintain OCSP code are very
often doing that for arguably legitimate reasons.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJVjGfFAAoJEKllVAevmvmsQvYIAIrkHX4rCC5fxox1xDTKZEyz
M/blTwJg1oMWhdS3YUIKLRE1B8wEp6WNvPzfhnsLTMHq0ssn1ci646xdsCPZO/TI
siT8MUIYKircOdKm12HVLu12/maEN4KZHq4xqtETJpLYSV+sUFkEBlGv4tFAdgt1
iDItm+cZhrLmYsIcnbt+q08dIj733DRsLHzGm7Dx8VV9bMI+4HjJhuKpSazmIZBe
/eANPvSLerHDycClsqKmxEjWZ+x3d/YhCmIhs8EMXhDT8RyQmmANCrD5iVeOgJF1
xvPy8jErVQkUW5B87AE8IsLvywACotTyStKiq2QhKbNDGrLoizkUvpVawBd4Fws=
=Uh4a
-----END PGP SIGNATURE-----