Date: Thu, 25 Jun 2015 16:44:54 -0400 (EDT) From: cve-assign@...re.org To: tmb@...35.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Validating OCSP response signatures -----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-----
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.