Tag Info

Hot answers tagged

10

Yes, a nation-state adversary can get a valid certificate for any site from any CA which they have power over. Whether it's legal or not is probably another question which I'm not qualified to answer. Keep in mind that, even if a hijacked CA starts signing certificates with CNs of popular websites like google.com in order to MITM their traffic, it will be a ...


9

From what information is out there, it seems like the most likely scenario was that the US Government wanted these companies to install back-door technology into their systems and give the government agencies access to all the information that flows through them; these companies would be ordered to not disclose the backdoor nor the government's involvement. ...


7

It's not standard for a commericial CA to insist on making your private keys. For reasons you mention. Here's a link pointing to a collection of CA providers that suggests (and rightfully so) that the typical thing is for your browser to create the key pair and then send the Certificate signing request to the CA. In my experience with high end Verisign ...


7

Yes you can. This example uses openssl smime with the default RC2 CBC with a 40-bit key. The newer cms sub-command behaves slightly differently, and uses 3-DES by default. You probably shouldn't be using either of those algorithms to encrypt important data ;-) There are two minor caveats: firstly, I'm also going to use a couple of other tools (though ...


6

The EFF's SSL Observatory has generated a map of all Certificate Authorities. This map is so massive, there is a very high likelihood that one of these is compromised at any given time. The principle of the weakest link makes me quite wary of our PKI. Furthermore, it is trivial for a nation-state to afford that cost of becoming a delegate authority. A good ...


6

There are several issues with email: Interaction with other email users without OpenPGP. You either reject them entirely or you have the receiving server do the encryption. Both of these are problematic. Silent circle chose the latter: People expect email to work universally, so we had to accept unencrypted mail from outside clients, which we then ...


6

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 ...


6

Signing emails is useful only insofar as recipients verify the signature. Theoretically, signing the emails might improve deliverability, but only if a recipient configures his filters for incoming emails to verify email signatures and accept emails which have been verified to come from you. However, this is only theoretical; in practice, email filtering is ...


5

PKCS#7 is an old standard from RSA Labs, published later on as an "informational RFC". Then, a new versions was produced, as an "Internet standard", i.e. with the seal of approval from the powers-that-be at IETF; a new name was invented for that: CMS. Newer versions were subsequently defined: RFC 3369, RFC 3852, RFC 5652. You can consider CMS and PKCS#7 to ...


5

Though a CA does not need the private key to issue a certificate, certificates for S/MIME will be used for encryption: once you have an S/MIME certificate, people will send encrypted emails to you, and the emails will remain encrypted in your mailbox. This implies that losing your private key (e.g. your compute hard disk fails, or your laptop is stolen) ...


4

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 ...


4

What you are looking for is theoretically viable, provided that you add the missing extra piece, i.e. some form of time stamping. However, behaviour of existing, deployed implementations is likely to be a problem. The conceptual idea is that if you verify a signature at date T on some message, then, at a later date T', you can still remember that the ...


4

I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal ...


4

To make a long story short: Yes, that will work and it will make sense, too. I'll try to explain this: PGP stores the signature inside the email body. The body of a PGP-signed mail usually begins with -----BEGIN PGP SIGNED MESSAGE-----, followed by the hash algorithm and the message clear text, followed by -----BEGIN PGP SIGNATURE-----, followed by ...


4

You can sign with both PGP and S/MIME. Contrary to Oliver Schmidt's response, it is possible to create an external signature using PGP (you can sign any file with a PGP key, not just text - a executable (.exe) is not a good candidate for inline signatures). This is referred to as "PGP/MIME". An external signature on a PGP file will be *.sig and S/MIME will ...


3

If you go to Comodo's page for the free S/MIME certificate, you may have a look at the "Subscriber agreement" which includes, in section 3.1, the following: The Subscriber's web browser will automatically generate a Private Key/Public Key pair during the signing up process. So it seems that the process involves a locally generated key pair, as it ...


3

If you have confidence in the security and policies of the company issuing the certificate (that they would not issue one to someone else for addresses in your domain) there should be no difference. Most of these shops offer the free e-mail certificates as a way to advertise to you for Web server certificates and the like. Many of the paid offerings provide ...


3

It depends if the CA is behaving properly when issuing certificates and if the person has been to your site before. If a CA is behaving properly when you get your certificate, they should not keep your private key. In fact in many cases, you can actually form your own private key if you wish. Provided that you have the only copy of the private key, all ...


3

PGP only works when both users are using PGP and already exchanged each others public keys over a trustworthy channel. When you want to send an email to someone you never had contact with you can not do that. Also, there is no good way for a web-based service to store the users keys on their own computer. There are features like cookies and localstorage to ...


3

1) FTP is a bit odd that it's still done, but phone and SMS don't normally require keeping logs of the content, so there is less information that can be subpoena'd. It's also the least easy for them to encrypt in such a way that information would reliably be protected from their legal requirements to cooperate for any insecure e-mail sent to them. 2) The ...


3

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 ...


3

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 ...


3

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 ...


3

For a single certificate, a PEM encoded format is common, this is the text/base64 one that is delimited by: -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- Most systems should accept .crt and .pem extensions for this file type, the former is slightly preferable for a certificate, .cer may work too. PEM is an encoding of data using base64 for the ...


3

The theory is that as long as you keep your old keys, your email software will still be able to decrypt your received emails. That the certificate is expired means that other people won't accept to use your old public key to send you new encrypted emails, but reading your mailbox on your side does not entail using your public key or your certificate, only ...


3

1: The advantage of S/MIME over PGP is that you sign/encrypt a complete mime entity, not a text. This makes it possible to sign/encrypt a entire message/rfc822. Yes, headers must be visible and changeable to the MTA, but that can be accomplished by taking the WHOLE mail, S/MIME sign or encrypt it, and then package the signed/encrypted S/MIME entity it in a ...


2

Short version: Certificates are based on validated trust and are more integrated into corporate mail systems PGP is based on "claims of trust", and support is not as wide across corporate mail systems


2

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.


2

Openssl has all the command-line utilities you need. It can work on x509 certificates and can also deal directly with S/MIME content. The verify utility is specifically for doing certificate chain validation, but that function is also built in to the S/MIME utility.


2

Some established CA will agree to sell you an intermediate CA certificate, but at a rather steep cost. There are several forces at hand here: An "established CA" is "established" by virtue of having its root key included in the usual browsers and OS. The CA operator could achieve that by signing a heavy contract with Microsoft, in which he promised to ...



Only top voted, non community-wiki answers of a minimum length are eligible