Tag Info

The main reason to prefer one technology over the other is usability. Regardless of the tools you use, email security will depend mostly on how well the users cooperate -- most of the confidentiality of their emails rests on their ability not to do anything stupid with their data, and to react appropriately in unusual conditions. You will get decent security ...

One cannot tell whether an implementation of CMS (aka "PKCS#7) is secure by looking at the produced file; at best, one could spot interoperability issues. I did not spot any interoperability issue right away; you use OAEP padding with RSA, which might be considered as bold (OAEP support is not completely widespread right now) but still conforms to the ...

In X.509, all revocation goes through objects signed by certificate issuers. The decision to revoke or not revoke is not in the hands of the certificate owner, but of its issuing CA. The CA makes its decision known by including or not including the target certificate serial number in the CRL it produces (ditto for OCSP responses, which are just CRL with a ...

There are details spelled out in RFC 3850. In practice: It is highly recommended to include your email address in your certificate, in a Subject Alt Name extension (or possibly as an extra attribute in the subjectDN but this is deprecated). If the certificate does not contain the email address, your correspondents will have to find another way to associate ...

That's because of "enforced". PGP uses a Web of Trust which is, by nature, decentralized. To enforce things, you need some hierarchical structure with a central point of decision, which X.509 provides (in this case, through the "self-signed CA at headquarters). In the PGP model, each user is the center of his own world and cannot be dictated his trust.

AS2 builds over S/MIME, so you need a certificate for S/MIME. Certificates for S/MIME are very similar to certificates for SSL, but some details may vary. See this answer for some details. You might want to generate your own certificates with some tool like OpenSSL. Godaddy is an established CA whose main asset is that their root public key is already known ...

There should be no reason to include the trust anchor (aka "root CA") into a signed email, because if the chain is to have any value for the recipient, then that recipient must already have it. Including the root CA in the email would only induce recipients into grabbing the root CA from the received email and inserting it in their trust store, which is a ...

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says: In general, this extension will appear only in end entity certificates. because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells ...