[kmail2] [Bug 385687] certification path validation

[Andre Heinecke]

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

Andre Heinecke <aheinecke at intevation.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://dev.gnupg.org/T3948
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |CONFIRMED
                 CC|                            |aheinecke at intevation.de

--- Comment #1 from Andre Heinecke <aheinecke at intevation.de> ---
Hello,

(In reply to ekaratsiolis from comment #0)
> for a project we evaluate the certification path construction and validation
> of different libraries and applications. One application on this set is
> KMail 5.1.3 with Kleopatra 2.2.0. We found a few issues which I present to
> you. Please find them at the end of the email.

Which GnuPG Version did you use for testing?

You can directly use GnuPG to test mails e.g.:

 ~/arbeit/kf5/build/gnupg/tools/gpgparsemail --crypto
smime/CERT_PATH_ALGO_STRENGTH_01.eml

Most of the issues here need to be fixed upstream as KMail itself does not do
any crypto, certificate checking or CRL fetching / caching. This is all done by
the GnuPG System. KMail is just a fronted.
These issues should have been raised in the GnuPG tracker (
https://dev.gnupg.org ) or on one of the GnuPG Mailing lists. So apologies for
the late reply but it was overlooked here a bit as the KMail developers are not
really responsible.

I've opened an upstream report https://dev.gnupg.org/T3948

> Especially CERT_PATH_COMMON_05 is interesting. In this case a certificate
> with wrong encoding is placed in the S/MIME structure. In this case the
> signature is ignored totally and the email appears as a standard email
> without signature.

This indeed appears to be a kmail issue. Although I would argue that showing an
invalid signed mail as secure as an unsigned mail is not very harmful. 

> Also the CRL tests could not be performed. Every CRL for each test is placed
> in a distinct crldp on the same server. Once the first test where one CRL is
> downloaded runs, it seems that for all later tests only the first CRL is
> used (cahcing), the new CRLs are not downloaded and the application
> evaluates the first CRL for resolving the revocation status of a
> certificate. Therefore almost every CRL test fails.

I can't really reproduce this there are crlDp's like:


http://certpath_test_host:8095/cert_path_crl_02/cert_path_crl_02_sub_ca_crl.crl
 ldap://certpath_test_host:389
CN=cert_path_crl_02_sub_ca_crl,OU=cert_path_crl_02,dc=certpath_test_host?certificateRevocationList?base?objectClass=cRLDistributionPoint

which of course won't work for me. Again. This should be reproducible by just
using GPGSM without KMail.


> Test Name | Evaluation | Expected Result | Application result |

I'll try to give it a more detailed look on Monday in the GnuPG tracker,
afterwards I can probably better say if there is something that KMail does
wrong, although I don't expect it (except for the minor problem where an
invalid signature is not shown)


Best Regards,
Andre Heinecke

-- 
You are receiving this mail because:
You are the assignee for the bug.