Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 25 Jun 2015 16:44:54 -0400 (EDT)
Subject: Re: Validating OCSP response signatures

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 ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.