[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
