Invoices/Payments/Receipts proposal discussion

[riplin]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

I believe most people don't know what OCSP stands for - so why would they not take me seriously asking about it?

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

[1714855188]

1714855188

[1714855188]

1714855188

[piotr_n]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

[kjj]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

Go educate yourself.

Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation.  So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client.

At some point, some form of OCSP probably will be implemented, because it is a very useful security feature.  When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky.

[riplin]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

Do you have a source for this?

[piotr_n]

Go educate yourself.

I fink you meant the other verb

Educating myself is exactly what I have been trying to do here, before you jumped in here, to insult me on behalf of the bitcoin elite.

Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation.  So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client.

Oh, thank you for finally making that clear, though...

At some point, some form of OCSP probably will be implemented, because it is a very useful security feature. 

Right. So we are going back to the entry point

When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky.

It is not me who said in this topic that the hash is sent to CA - I only repeated it, since you were not here to state it wrong.
Go educate yourself.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

Do you have a source for this?

https://en.bitcoin.it/wiki/BIP_0070

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

[kjj]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

[piotr_n]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

https://bitcointalk.org/index.php?topic=128442.msg3402965#msg3402965
https://bitcointalk.org/index.php?topic=128442.msg3403915#msg3403915

Why would he think so? Maybe because he followed your advise and educated himself...

EDIT:
Sorry - one of the links points to a post of a non-supporter.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

Given the circumstance in which the CA system produces the signature for the Payment Request message, how can a valid signature be produced that the CA did not sign?

[kjj]

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA.  Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest.

[piotr_n]

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA.  Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest.

Where do you get the root certificates from?
Or let me ask otherwise, make it a simpler question: which openssl function do you use to verify a certificate and the message, and how do you know what this function does inside?

[jgarzik]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

[piotr_n]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

So it does not support a chained certificates?

The bitcoin client does not need to connect to the CA.
All it takes is an SSL lib connecting there, likely even on the OS level, since the root certs are installed right there.

You guys obviously don't quite understand how this protocol works inside, and it's obvious since it is a one big mess and nobody does, but don't you think that merging the bitcoin client with a lib that nobody really understands might be a bit dangerous, to say the least?

[riplin]

From this, you can see that the Payment Details message is contained in the overall PaymentRequest message (in the serialized_payment_details variable). What I've tried to highlight is, that:

• your Bitcoin public key (message Payment Details { repeated Output outputs })  
• the Merchant's message for details of the request (message Payment Details { optional string memo })
• your IP (message Payment Details { optional string payment_url })

That is not YOUR IP. It's the merchant's return URL where the payment message is sent and a payment ack is retrieved.

are all contained in the presiding message PaymentRequest variable {required bytes serialized_payment_details}.

If you look at the description in the section for the PaymentsRequest message that describes the composition of the signature, also bolded, you'll see that the PaymentRequest message itself is hashed using the public key (optionally) provided by the merchant.

the message isn't "hashed using the public key". It's simply hashed. And it's signed with a private key. This all happens on the merchant's server.

What concerns me is that I have no idea whether the data in the Payments Details (non-mandatory as some of it is) can be somehow cajoled into something meaningful,

I think that you're not entirely up to date on what hashing does. It is nothing more than jumbling together the input data in a thoroughly destructive manner that produces an output that is impossible to reverse. This is a reproducible operation. Meaning, every time you feed it the same input data, it will produce the same output hash.

given that the nature of the hashing of this information involves using a certificate to authenticate that some of the contents of the hash are verifiable.

You've got it the wrong way around. The PaymentRequest is hashed using either SHA1 or SHA256 and that hash is then signed using the private key. The reason that is uses a hash is because of how the signature function works. It's simply an irrelevant implementation detal.

This signature can then be verified using the public key contained in the merchant's certificate. The merchant's certificate is verified using the rest of the chained certificates in the PaymentRequest, all the way up until the ROOT certificate is needed, which is either already present on your computer or can, as the BIP suggests, be requested from the Mozilla Root Store. At no point is any information in this process sent to the CA.

The PKI public key of the merchant must be positively identified from within the hash of the information, so is the rest of the hashed information also safe?

No, wrong way around. You cannot extract information from a hash. That's the sole purpose of hashing; producing a reproducible number that cannot be reversed.

[Carlton Banks]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

Which bitcoin client? The users or the merchants? Some party can do so, whether it's through the Bitcoin client or not.

It would reflect better on the core devs if they were not defensive, aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

[riplin]

Where do you get the root certificates from?

People have already told you several times that the root certificates are either already present on your computer (supplied by the operating system) or can be fetched from the Mozilla Root Store.

Or let me ask otherwise, make it a simpler question: which openssl function do you use to verify a certificate and the message,

You don't need openssl to test if a certificate is valid. you can use any crypto library you fancy. depending on the crypto method used, this could be an RSA library or an EC library.

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

[piotr_n]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.
E.g.: how do you know which root certificates are installed in the system? Let's say Windows...

So it's totally cool that you play a smart ass pretending that you know how it works, but before you can explain me the details, I cannot really assess if you are not just playing stupid

[riplin]

It would reflect better on the core devs if they were not defensive

And it would reflect better on you if you tried to actually figure out some of the basics first. You've shown a significant lack of understanding of even something as simple and instrumental as a hash function.

aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

There have been multiple clarifying posts in this thread, yet you continue to ignore them.

[kjj]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

Given the circumstance in which the CA system produces the signature for the Payment Request message, how can a valid signature be produced that the CA did not sign?

Ahh.  The problem then is that you don't know how SSL PKI works.

The CA generates a private key, and a matching public key.  The pubkey is packaged into a certificate, which is then signed by the privkey (which is funny, because it is a self-signature, but it still provides some assurances).  They then publish that certificate.

The merchant generates their own private key and the matching pubkey.  They package that into a certificate with some identifying information, which is sent to the CA.  The CA signs the merchant certificate with their private key and sends it back.

The merchant then generates a payment request, hashes it, and signs the hash with their private key.

You get the request, the signature and the certificate.  Your software verifies that the attached certificate does indeed correspond to the signature.

To verify that the certificate you are looking at does indeed belong to the vendor you think it belongs to, your client checks that the certificate it received has been signed by a trusted CA.  In this simple example, the CA's published pubkey has been included in the client through some out-of-band mechanism (hardcoded into the source maybe).

You will notice that at no time during your transaction is anything sent to the CA.  The CA isn't signing your specific message, they already signed the merchant's certificate, and the merchant's private key is used to sign the request.

There are two wrinkles that can be added to the simple example.  The first is when the CA doesn't sign your certificate directly.  In that case, the merchant sends a certificate chain.  Your client then follows the chain backwards, making sure that the merchant's cert has been signed by X, and that X was signed by Y, and so on until certificate Z was signed by the CA.

The second is OCSP.  In OCSP, your client can look in the merchant certificate for a field specifying the OCSP server.  Your client can then ask the OCSP server if the certificate it is looking at is still valid.  If the certificate was signed in error, or if the private key for it was stolen from a compromised server, you can find that out in real time using OCSP, and potentially reject the transaction despite having valid signatures.

(There is also a variation of OCSP called OCSP stapling where the server, rather than the client, requests proof of validity from the OCSP server and attaches it to the certificate.  This is better for privacy, since your client doesn't then need to tell the CA that someone from IP address X is checking on the certificate issued to Y.  OCSP already has a timestamp and a validity window, and are signed, so it doesn't really matter who asks for it or which servers it passes through in transit.)