Topic: Can we talk about removing SSL from the payment protocol and put PGP? - page 2. (Read 2455 times)

Because an implementation contained a bug (now fixed) you want to change the protocol? Makes no sense.

Well my main focus is getting a decentralized key server, if it supports SSL first then pgp then fine.

openssl ecparam -genkey -name secp256k1 -out e:\server.pem
openssl req -new -x509 -nodes -sha256 -key e:\server.pem > e:\server.cert

openssl x509 -in e:\server.cert -text -noout

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            cd:a5:2d:4d:4c:b1:34:94
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=I am as secure as bitcoin itself
        Validity
            Not Before: Apr  9 19:51:02 2014 GMT
            Not After : May  9 19:51:02 2014 GMT
        Subject: CN=I am as secure as bitcoin itself
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:86:80:e3:3b:d6:0e:ab:13:bf:03:5e:ca:02:04:
                    4e:e1:82:7e:10:50:b1:9d:75:d9:4e:63:c6:75:9b:
                    7f:2b:06:c8:e1:11:9c:63:5c:25:29:6a:d3:8f:ee:
                    ae:b0:64:6d:36:80:29:6b:85:ce:73:98:fe:68:22:
                    cf:df:f6:62:53
                ASN1 OID: secp256k1
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                14:ED:A5:89:CD:E8:AB:AA:BF:1D:6D:70:17:81:14:C1:B2:51:BC:3E
            X509v3 Authority Key Identifier:
                keyid:14:ED:A5:89:CD:E8:AB:AA:BF:1D:6D:70:17:81:14:C1:B2:51:BC:3E
            X509v3 Basic Constraints:
                CA:TRUE <-should probably be false but didn't feel like setting up config file
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:65:10:58:29:47:c8:3d:b7:aa:d0:ef:fc:80:47:
         4e:72:77:e5:a5:58:48:0d:6c:37:8f:fc:3d:fc:e1:34:cd:b3:
         02:20:4d:14:5e:8f:0d:31:35:84:20:2d:5a:be:6a:3a:ea:e0:
         7a:69:6d:1e:45:66:4f:5b:e2:d8:57:59:2f:27:4d:ba

I am also not a big fan of openssl, that also is playing into it. I rather they used http://nacl.cr.yp.to/.

Well the subtleties do matter. X509 CAN support weak signature algorithms but it can also use require only cryptographically strong algorithms as well.


The support for older weaker algorithms is mostly for backwards legacy support, support which isn't needed for a greenfield implementation.  No reason that a particular users (or any user) would need to support weak signature algorithms.  You can also use MD5 to hash PGP messages as well. 

If both can be implemented without CAs, both can support key servers, both can use a node network for DHT storage of public keys and/or certs then ultimately the only advantage of using PGP over SSL would be that it is more secure.  Sorry you haven't shown that PGP would be more secure than self signed SSL certs.    This isn't an academic debate.  It is almost certain that Bitcoin will support SSL in payment protocol so it doesn't come down to PGP vs SSL it comes down to SSL vs SSL + PGP.  Adding another entire dependency just because weak SSL certs might be weak (and strong ones are cryptographically unbreakable) is well not a very strong argument.

Well technically you can use a X509 to relay pgp information. I think a PGP certificate would be stronger and better in this case. Also X509 is weak with the signature algorithms, you don't need a link to show that.

openssl req -new -x509 -sha512 ...

No it's not false.  TLS (per its name) happens at the transport layer.  It's baked into every http library in the world.  There really isn't a standard to do this for OpenPGP that anyone uses or is supported by any library.  What you're proposing requires everyone to implement an ad-hoc poorly specified made-up-just-for-bip-70 encryption scheme and shoving it into the presentation layer.

This is very much false, all information could be encrypted using the public key of the user that wants to send the bitcoins and then decrypt by their machine. Also I wouldn't include gpg into the actually bitcoin client I would have it called out to the shell so their is a disconnect of passwords and stuff.

There isn't a widely used transport layer standard for OpenPGP, which is what the protocol needs, so TLS is probably a better choice then PGP for the actual encryption.

How would Bitcoin support PGP client public keys?  Whatever the solution replace PGP public key with SSL Client cert.  Not saying SSL is better but not seeing how we gain anything by going to PGP.


Ok now we are talking or at least to the heart of the matter.  Do you have a cite or link where X509 would fail that PGP wouldn't?

Yes SSL protocol supports it but no browsers (Firefox does) really support that feature, no web server really makes use of that of feature. So what makes bitcoin going to support?

Well the X509 also isn't that strong. I mean if people think that SSL cert would work better in a decentralized environment I am open to it but I don't think SSL certificates aren't strong enough for this.

That is a valid point although SSL does support client certs.  Bitcoin would be extended to expose that support making it identical to PGP in that respect.

All of that can be done with SSL self signed SSL certs as well.  I guess my point is you seem to be indicating that CA = bad therefore don't use SSL.  SSL can be used in a self signed fashion.  You could have SSL self signed key servers, you could load them into the network DHT style essentially replace public key in your example with SSL cert and the same thing applies.

With PGP we could validate two way, that the company is talking to the right user and user could be talking to the right company.

  Also PKI are expensive so we can't really have any community involvement this yet. Where is we used a key server that was decentralized like using a DHT, we can then not have to worry about hacks on CA's or it being expensive to start your own.  We also could use each full node be a key server and then you query everyone of them for the public key for the company you want to validate from. With majority rule on what is the correct public key.

Indeed. 100% agreed.

I'm certainly not against better, more distributed alternatives to the payment protocol. BIP0070 was not meant as the be-all and end-all idea, but a immediate workable solution.

But there has been enough talk on this subject. Long, handwavy discussions are just not useful. Show us code.

Not trying to flame gweedo but what would we gain from using PGP over say self signed SSL cert?  SSL doesn't need to mean that CA are used.

If you write good patches to add PGP/WoT authentication, I suspect they would be merged in a heartbeat.

As far as I can tell, no one is opposed to such a thing, they just don't think it has a very good payoff to effort ratio compared to authentication using the global SSL PKI.  Because of this, it is not a good candidate for being built first.  If you disagree, feel free to write some code, or convince/bribe someone to do so.

If you write good patches to add PGP/WoT authentication, I suspect they would be merged in a heartbeat.

As far as I can tell, no one is opposed to such a thing, they just don't think it has a very good payoff to effort ratio compared to authentication using the global SSL PKI.  Because of this, it is not a good candidate for being built first.  If you disagree, feel free to write some code, or convince/bribe someone to do so.