[kmail2] [Bug 385687] certification path validation

[Andre Heinecke]

https://bugs.kde.org/show_bug.cgi?id=385687

--- Comment #8 from Andre Heinecke <aheinecke at 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 the assignee for the bug.