[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: [oss-security] Re: Validating OCSP response signatures
From: cve-assign () mitre ! org
Date: 2015-06-25 20:44:54
Message-ID: 20150625204454.AAC33ABC3A3 () smtpvmsrv1 ! mitre ! org
[Download RAW message or body]
-----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-----
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic