Tag Info

Hot answers tagged

9

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


6

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

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

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

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


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


5

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


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


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

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


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

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


2

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


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

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

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


2

Let's give it a chance: If you have a key which expires in a year, all the data sent signed with that key within that year is valid forever (unless the key have been exposed), the problem here is, has the data or the application which uses it the correct information about when it was generated? (date signature stamp). A different problem may be, hey, you ...


2

A hierarchical public key infrastructure is when some Certification Authority (CA) issues certificates to a lot of sub-entities: the CA signs certificates to guarantee the link between an identity and the public key owned by that entity. The PKI is hierarchical in that there are few CA and each CA signs certificates for a lot of people. In a Web of Trust, ...


2

If you are afraid of "snooping" then why would you use signatures ? A "snooper" is a passive eavesdropper, who wants to see the data but certainly not to make you aware that your emails are inspected. They won't alter emails, or send fake emails, which are the kind of things that signatures can help against. If you want to defeat such sniffing, then you ...


1

When you say password, are you referring to the password for the email account, the password to secure the s/mime cert, or the smartcard password (pin)? Ultimately the attacker needs access to the private keys so it depends how they're stored. If they're on a smartcard, then the smartcard must be present to perform the cryptographic operations. If they're ...


1

As far as I know, S/MIME doesn't use passwords, but private and public key pairs. So, the private and secret thing is user's private key. If private key is stolen, it can reveal the content. If you want to prevent stealing privkeys you (or each user) should store them in safe place. If your privkey is stolen, you should asap revoke the certificate (with ...



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