https://bugs.kde.org/show_bug.cgi?id=385687
--- Comment #8 from Andre Heinecke <aheine...@intevation.de> --- Hi, thank you very much for that input. (In reply to ekaratsiolis from comment #7) > CERT_PATH_ALGO_STRENGTH_01 (and ..._02). > > Lots of libraries still accept weak algorithms for compatibility reasons. > This does not prohibit the user for example to use them for verifying a > digital signature and accept rogue (or valid) certificates. The possibility > to configure which algorithms are accepted could be an option here. Our (GnuPG) Idea is that administrators should take care when setting up the PKI for their Organizations, and if they don't accept root CA's which use weak algorithms and that it is basically similar to "configure which algorithms are accepted". That said, I do agree, MD5 Signatures should be rejected by default. That is why I opened an issue for that. > CERT_PATH_COMMON_05. > > For KMail this leads to present the email as a normal email. Here someone > could just flip a few bits and the receiver cannot notice that there was a > problem. In my opinion KMail should not show an invalid signed mail worse as an unsigned mail. An attacker could just remove the signature and be done with it. Although I agree that the error should be shown, albeit not very prominently. I really really hate the Red color in signature verification from a user experience standpoint. ;-) In short: As an attacker I would either send an unsigned mail or remove the signature before I change a signed mail to make it invalid. So the invalid state does not need to be shown more prominent then the unsigned state. > Wrongly encoded certificates are infamous for buffer overflows. I hope that the fuzzing tests which the Community regularly does against GnuPG would have detected such a problem. There were indeed several Problems in LibKSBA (the X509 Parser lib) which were fixed after fuzzing tests. > CERT_PATH_COMMON_08 (and ..._10). > > This is important since expired certificates are allowed to be removed from > the CRL. Not checking whether a certificate has expired may result to a > missed revocation. > > Please note that there are other so called validity models (chain model and > hybrid model) where this check is not that important, in the internet PKI > however the shell model is used (everything must be valid in verification > time) and this check is important. Yes. This is bad in the GnuPG System. I raised this issue to high priority and see to it that it will be fixed in the next release of either GPGME or GnuPG, which will automatically fix any KMail version using such releases. > CERT_PATH_COMMON_13 > > This is not conforming to the specification, which allows self-signed > certificates in the path. This does not happen often in practice. In agreement here. We have an Issue but nothing serious. > CERT_PATH_EMAIL_04 > > This is not conforming to the specification, which mandates this certain > extended key usages (see RFC 5280 [Sec. 4.2.1.12] and RFC 5750 [Sec. > 4.4.4]). If a CA needs to limit the usage of a certificate (for whatever > reason) this is not taken into consideration by the client. The extended usage attributes not well supported by GnuPG. It was not yet a priority for our users / customers to fix that. But yes, it's an issue. Thanks again, Andre -- You are receiving this mail because: You are watching all bug changes.
