Use embedded certificates about secon-tool HOT 7 CLOSED

Indeed, including the signer's certificate in the SignedData structure would enable recipients to verify the signature without further lookups in LDAP or keystores. Will discuss this internally.
Including the whole chain should be optional since in most cases validation of the cert chain in TLS should be sufficient.

from secon-tool.

There's one issue with this approach: If the signer's certificate is embedded and only this information is used to verify the signature then the authenticity of the message is not guaranteed.
With the current implementation if one sends a message as e.g. "IK12345678" the recipient will lookup the public key (from its own trusted source) for "IK12345678" to verify the message signature. Thus, only senders with possession of the private key for "IK12345678" will be able to generate an accepted signature.

When an embedded certificate is used to verify the signature, "IK66666666" can create a message in the name of "IK12345678" but sign as "IK66666666" with the certificate attached. The recipient has no way to tell if the sender really is "IK12345678".

from secon-tool.

Of course, the embedded certificate chain needs to be recursively verified. For the verification of the last element in the chain you need to look-up a root certificate from the LDAP server. This is a standard algorithm which is also used in TLS et al.

If you combine this with a cache, this results in a very efficient solution where typically only a single root certificate is ever loaded from the LDAP server and then held in the cache for the verification of all embedded certificate chains.

from secon-tool.

Just a question:
Does this have issues with "Leistungserbringer"?
In our case we are "man in the middle", so we are sending files for our customers, signed with the certificate of our IK number.
Actually we have the case, that the recipient is not able to decrypt the file, because of 'CertificateNotFoundException', but they should, because they definitley do have our certificate in the LDAP directory we used for sigining.

from secon-tool.

Your issue is unlikely to be related to this discussion, but it could be caused by issue #35 . A fix has already been merged into master and will be published with the next release.

from secon-tool.

Of course, the embedded certificate chain needs to be recursively verified. For the verification of the last element in the chain you need to look-up a root certificate from the LDAP server. This is a standard algorithm which is also used in TLS et al.

If you combine this with a cache, this results in a very efficient solution where typically only a single root certificate is ever loaded from the LDAP server and then held in the cache for the verification of all embedded certificate chains.

While validation of a certificate chain to a trusted root (e.g. PKIX path validation) would be a nice-to-have feature I don't see how this would help with a certificate renewal. To authenticate the sender one would still need to verify the sender's certificate actually belongs to the entity (e.g. IK123456) given in the message.
Further, since this tool is mostly used behind a (m)TLS connection certificate chains are already validated on the TLS level.

from secon-tool.

The embedded certificate is important.
We got this answer from "davaso":

ihre Daten sind korrekt verschlüsselt, leider können wir die Signatur aber nicht prüfen weil Ihr Zertifikat nicht mit enthalten ist.
Ihr Zertifikat muss Zusammen mit der Signatur mitgeliefert werden, zusätzlich sollte auch noch das Zwischenzertifikat das sie vom Trustcenter erhalten
haben eingefügt werden. Diese Zertifikate müssen in der verschlüsselten Datei mit enthalten sein, also nicht als zusätzliche Datei mitliefern.

Das ganze sieht wie ein Fehler von Ihrer Software aus, normalerweise haben sie darauf als Anwender keinen Einfluss.

After telling him, that we are having the serial number of our certificate inside they told us, that in the specification (Anlage 16, 3.2) is:

Der Typ SignedData besteht allgemein aus den zu signierenden Daten, den für die Verifizierung der Signatur notwendigen Zertifikaten sowie Informationen zu dem signierenden Absender.

So to be a valid file, the certificate of the signer has to be inside.
Otherwise some of them will decline the transferred files.

from secon-tool.