Re: Idea: Using GPG signatures for SSL certificates
Thomas Shadduck writes: The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities when they get compromised, everything they signed gets compromised too. Technically this is true, but the only thing that the CA signs is other keys. So it merely means that the CA can create certificates on behalf of anyone the compromisers choose. It doesnt compromise any existing key or previously issued certificate or even any newly created key. In any case, you dont need a CA to use SSL. (Or more accurately, you dont need anyone elses CA to use SSL just create your own CA and issue yourself a certificate. This can be done without a lot of effort using openssl, for example.) However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. What exactly does this buy you? The SSL certification authority system has as its only (but useful) redeeming value that one can connect to www.somecompany.com and have some level of confidence that the SSL certificate presented by that site was actually issued to www.somecompany.com and was issued by a reputable certification authority -- one that presumably will not hand out a certificate stamped www.somecompany.com to [EMAIL PROTECTED] If the certificate presented is not from one of the recognized reputable CAs built into your web browser, SSL itself will still work but your web browser will pop up a box saying that the CA is not in its list of reputable CAs (and BTW would you like to connect anyway? yesno). I dont understand the mindless worship of the web of trust. PGP (/GPG) is a useful tool, but the web of trust is simply a way of certifying a key in a non-centralized, non-hierarchical way. -- Frondeur
Re: Idea: Using GPG signatures for SSL certificates
Thomas Shadduck writes: - cute :) Though I am more often called Shaddup. The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities when they get compromised, everything they signed gets compromised too. Technically this is true, but the only thing that the CA signs is other keys. So it merely means that the CA can create certificates on behalf of anyone the compromisers choose. It doesnt compromise any existing key or previously issued certificate or even any newly created key. By compromised I meant the signature confirming the authenticity of the certificate can't be trusted anymore. Sorry if it wasn't obvious. In any case, you dont need a CA to use SSL. (Or more accurately, you dont need anyone elses CA to use SSL just create your own CA and issue yourself a certificate. This can be done without a lot of effort using openssl, for example.) I am aware of this. Using the GPG/SSL approach, you can have your own in-house CA for SSL purposes, and at the same time be able to prove to external users that the certificate is really yours. One more factor for establishing trust, one more obstacle for the Adversary to pass. However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. What exactly does this buy you? The SSL certification authority system has as its only (but useful) redeeming value that one can connect to www.somecompany.com and have some level of confidence that the SSL certificate presented by that site was actually issued to www.somecompany.com and was issued by a reputable certification authority -- one that presumably will not hand out a certificate stamped www.somecompany.com to [EMAIL PROTECTED] It won't buy me anything new. It only strengthens the confidence level by providing a CA-independent, alternative method of verifying the certificate. If the certificate presented is not from one of the recognized reputable CAs built into your web browser, SSL itself will still work but your web browser will pop up a box saying that the CA is not in its list of reputable CAs (and BTW would you like to connect anyway? yesno). What I'd like is one more button, Attempt to verify by GPG. Though that can be easily done by an external application; browser integration is nothing more than mere comfort. I dont understand the mindless worship of the web of trust. PGP (/GPG) is a useful tool, but the web of trust is simply a way of certifying a key in a non-centralized, non-hierarchical way. YES! Which is what I want to achieve.
Idea: Using GPG signatures for SSL certificates
The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities; when they get compromised, everything they signed gets compromised too. However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. The server presents its certificate to the client. The client then can optionally request the GPG signature of the certificate from the server either by always trying if it is there or only if its presence is indicated in the certificate data fields, and verify it by the specified GPG public key (which then can be firmly embedded in the web of trust). The server's key may be stored on the server itself together with the certificate signature file, or the signature file may indicate the keyserver it should be fetched from. Being signed by several trusted keys is crucial for this purpose, as otherwise it would be trivial to compromise the GPG pubkey together with the signature and the SSL certificate, if the adversary gets access to the server and manages to compromise the CA (risk especially with in-house CAs, or when Agencies get involved). The clients should cache the server's authentication information, and report any changes, like SSH does. The location of the signature may vary; it can be stored in a default place on the server (https://secure.server.com/cert-gpgsignature.asc), or the location can be specified in a X509 field. Is it a good idea? Could it fly? If not, why?
Re: Idea: Using GPG signatures for SSL certificates
Thomas Shadduck writes: The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities when they get compromised, everything they signed gets compromised too. Technically this is true, but the only thing that the CA signs is other keys. So it merely means that the CA can create certificates on behalf of anyone the compromisers choose. It doesnt compromise any existing key or previously issued certificate or even any newly created key. In any case, you dont need a CA to use SSL. (Or more accurately, you dont need anyone elses CA to use SSL just create your own CA and issue yourself a certificate. This can be done without a lot of effort using openssl, for example.) However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. What exactly does this buy you? The SSL certification authority system has as its only (but useful) redeeming value that one can connect to www.somecompany.com and have some level of confidence that the SSL certificate presented by that site was actually issued to www.somecompany.com and was issued by a reputable certification authority -- one that presumably will not hand out a certificate stamped www.somecompany.com to [EMAIL PROTECTED] If the certificate presented is not from one of the recognized reputable CAs built into your web browser, SSL itself will still work but your web browser will pop up a box saying that the CA is not in its list of reputable CAs (and BTW would you like to connect anyway? yesno). I dont understand the mindless worship of the web of trust. PGP (/GPG) is a useful tool, but the web of trust is simply a way of certifying a key in a non-centralized, non-hierarchical way. -- Frondeur
Re: Idea: Using GPG signatures for SSL certificates
Thomas Shadduck writes: - cute :) Though I am more often called Shaddup. The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities when they get compromised, everything they signed gets compromised too. Technically this is true, but the only thing that the CA signs is other keys. So it merely means that the CA can create certificates on behalf of anyone the compromisers choose. It doesnt compromise any existing key or previously issued certificate or even any newly created key. By compromised I meant the signature confirming the authenticity of the certificate can't be trusted anymore. Sorry if it wasn't obvious. In any case, you dont need a CA to use SSL. (Or more accurately, you dont need anyone elses CA to use SSL just create your own CA and issue yourself a certificate. This can be done without a lot of effort using openssl, for example.) I am aware of this. Using the GPG/SSL approach, you can have your own in-house CA for SSL purposes, and at the same time be able to prove to external users that the certificate is really yours. One more factor for establishing trust, one more obstacle for the Adversary to pass. However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. What exactly does this buy you? The SSL certification authority system has as its only (but useful) redeeming value that one can connect to www.somecompany.com and have some level of confidence that the SSL certificate presented by that site was actually issued to www.somecompany.com and was issued by a reputable certification authority -- one that presumably will not hand out a certificate stamped www.somecompany.com to [EMAIL PROTECTED] It won't buy me anything new. It only strengthens the confidence level by providing a CA-independent, alternative method of verifying the certificate. If the certificate presented is not from one of the recognized reputable CAs built into your web browser, SSL itself will still work but your web browser will pop up a box saying that the CA is not in its list of reputable CAs (and BTW would you like to connect anyway? yesno). What I'd like is one more button, Attempt to verify by GPG. Though that can be easily done by an external application; browser integration is nothing more than mere comfort. I dont understand the mindless worship of the web of trust. PGP (/GPG) is a useful tool, but the web of trust is simply a way of certifying a key in a non-centralized, non-hierarchical way. YES! Which is what I want to achieve.
Idea: Using GPG signatures for SSL certificates
The problem that makes me feel uneasy about SSL is the vulnerability of the certification authorities; when they get compromised, everything they signed gets compromised too. However, the system could be for some applications potentially get hardened to certain degree, using the web-of-trust approach. The server presents its certificate to the client. The client then can optionally request the GPG signature of the certificate from the server either by always trying if it is there or only if its presence is indicated in the certificate data fields, and verify it by the specified GPG public key (which then can be firmly embedded in the web of trust). The server's key may be stored on the server itself together with the certificate signature file, or the signature file may indicate the keyserver it should be fetched from. Being signed by several trusted keys is crucial for this purpose, as otherwise it would be trivial to compromise the GPG pubkey together with the signature and the SSL certificate, if the adversary gets access to the server and manages to compromise the CA (risk especially with in-house CAs, or when Agencies get involved). The clients should cache the server's authentication information, and report any changes, like SSH does. The location of the signature may vary; it can be stored in a default place on the server (https://secure.server.com/cert-gpgsignature.asc), or the location can be specified in a X509 field. Is it a good idea? Could it fly? If not, why?
