# Tag Info

## Hot answers tagged certificates

7

Yes, obviously if the CA generated your private key, they might keep it and share it with anybody. Yes on both counts. In fact, the normal way to generate a certificate -- whether for a Web server (TLS) or for yourself (S/MIME or TLS client) -- is to create a "Certificate Signing Request" and send it to the CA. The CSR includes your public key, not your ...

6

If the KGC gets compromised it will break security, so why should a KGC generate private keys. Certificateless crypto tries to overcome the problem which exists in identity based crypto, i.e., that the KCG generates all the private keys of the users (that is necessary in IBE, see below) and thus knows all the private keys of users (which in turn enables ...

6

A lot of sleepless nights for the CA, their customers, web browser and OS developers, and Slashdot users, that's what. I don't know if a CA has ever had their private keys compromised, but there have been incidents where their systems were broken into and fraudulent certificates were issued. (There's a difference between a private key actually being taken, ...

4

That's correct. If this happens, then your PKI is doomed and you have to set it up again and roll out all the certificates again. Actually, then not all the certificates are "compromised" in the sense of key compromise, but you cannot longer trust them, since if someone is in possession of the root private key, this person can issue arbitratrily dated ...

4

To answer this question, we must have a look at how TLS/SSL works. I guess you know that the aim of TLS/SSL is to authenticate communicating parties before setting up an encrypted connection through which application data will flow. And as you may already know, an SSL handshake/session will use asymmetric crypto for authentication and session setup and ...

4

If you use public key crypto in the correct way, then every user has it's own private key and corresponding public key (included in the certificate) and the keys of users are not related. Consequently, compromising the private key of one user does not affect any of the other users. So in the case of compromise of the private key of one user the remaining ...

3

There was a post on security.stackexchange last week about this. SSL/TLS with Certificate Authorities for all intents and purposes is now completely insecure from governments and any organisation who has a CA pre-trusted inside the standard web browsers. DNSSEC will also fall under the same scenario because at the top level you have a particular government ...

3

Although x.509 is the standard for PKIs with CAs, different certificate formats have been defined for the other 2 major PKI approaches: SPKI has defined its own certificate format , still (forever?) in draft status. Web-of-Trust models usually use the OpenPGP certificate format defined in RFC2440 RFC4212 "Alternative Certificate Formats for the ...

3

Quote from http://www.digi-sign.com/node/10922 All Types of Digital Certificates Are Also a X509 Certificate A X509 certificate *refers to all types of digital certificates, regardless of how they are utilized, and implies the current standardization used to design and create digital certificates. This standardization recognizes that the ...

3

You've stumbled on the requirement for authentication. Recall that signature schemes have a private key and a public key. The private key is used to sign the document in question, and the public key is given to the verifying party so that they can verify that the signature is correct. You're correct that it is possible to strip a digital signature and ...

2

There is "PGP network of trust" (also implemented by other OpenPGP-compatible systems like GnuPG) which does exactly that. You start off with nobody to trust except yourself. You decide to trust some friends of yours and hand your public key to them to have it signed. This signed public key will be automatically trusted by anyone else who trust your ...

2

Another approach is done by the Perspective Project. With it you setup your server and it will monitor the certificates of the sites. You can then subscribe to any number of these monitoring servers and verify them against each other. Since you decide which ones you want to trust, instead of 1 certificate being certifiable by just 1 person, it should be ...

2

The revocation status of a certificate is application depended, meaning that if the application under which you perform the encryption or decryption does not check for revocation status with the CA, then you may still proceed and encrypt or decrypt the message. You should consider the loss of a private key of a certificate as a loss of your password in a ...

2

If you can put the entire PGP certificate in a proprietary non-critical extension then you don't need to find the PGP certificate in a store. This solution depends on the condition that you are able to create your own OID and insert the PGP certificate in the extension. Furthermore, the server should accept such a certificate and contain methods of ...

2

I still got the impression that you did not really have read my answer to a related question. But still, I try to briefly answer your questions here. First of all, private key extraction essentially means private key generation. Extraction, because the partial private key ($D_A$) is generated with repsect to an identity string $ID_A$ uniquely identifying ...

2

That depends on the concrete CRL. As long as you have access to your private key, you can sign the revocation request. This prevents anyone without access to the private key from issuing a faked revocation request. With access to the private key, a faked revocation request can be sent. But in this case the damage is already done, and a revocation is ...

2

\$ openssl genrsa | openssl rsa -text -noout Private-Key: (512 bit) modulus: 00:e7:be:c0:b7:7a:8a:e6:58:c3:dc:3e:eb:ed:bc: a7:15:04:78:8d:9d:fe:a2:83:aa:ca:85:5f:4b:ae: 5c:fa:3d:bd:2b:a9:91:58:e1:da:d8:8a:bd:25:6d: 07:10:74:52:2f:ee:ce:bd:3c:c6:89:01:2e:ff:9a: 3b:61:4d:e7:81 publicExponent: 65537 (0x10001) privateExponent: ...

2

Firstly, PKI makes use of a private key and a public key. The private key is known only to the user, while the public key is communicated securely via the use of certificates. To provide authentication and non-repudiation, users may sign a message with their private keys and obtain a digital signature. Any other users can verify that the signed signature is ...

1

No, in general re-using keys is not advisable. Even if you would have a secure token then it would be better to have multiple keys stored in it. In general the level of security required for certificate authorities is higher than the security required for personal use of a key. If you later want to your CA key within a smart card or HSM then it should also ...

1

In Kerberos, if the Key Distribution Center is compromised then all the stored keys are exposed. In PKI, if a Certificate Authority is compromised then certificates may be forged. So, I guess we typically assume that the "trusted" third party will not be compromised so easily? Because either method you choose, there are still some inherent risks.

1

You can search for root certificates of a given CA. E.g.: http://www.symantec.com/page.jsp?id=roots, but this page is served over plain HTTP so maybe you shouldn't trust it! or https://www.mozilla.org/projects/security/certs/included/. From there when you want to check a certificate you can check whether it belongs to/was signed by a root CA you trust. ...

1

SSL offers protection against Man-in-the-Middle only if the client can make sure that what it believes to be the server's public key is, indeed, the true server's public key. X.509 certificates aim at providing this information, but this is relative that no rogue CA was involved. A "rogue CA" is here one of: An evil or gullible root CA ("subverted" CA ...

1

I'm not quite sure if I understand you correctly. As far as I understand it, you want to produce a threshold signature on the hash value of an X.509 certificate. It is not sure if you require a distribute key generation of the private key, or you are in possession of the signing key and distribute shares of the key to all stakeholders. 1) Actually, in ...

1

This is impossible - the receiver knows nothing about you so there's no way he can assure that the sender is in fact you.

1

First of all, as already mentioned in the comments, there is absolutely no mathematics or cryptography involved. Independent of the model used, i.e., public key cryptography, identity based cryptography, or certificateless public key cryptography (as i summed up in my answer here), the identity verification must be established by other means. In the wild ...

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