View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004629||Taler||other||public||2016-08-25 17:45||2023-04-04 18:00|
|Reporter||Florian Dold||Assigned To|
|Priority||low||Severity||feature||Reproducibility||have not tried|
|Summary||0004629: certificates for merchant public keys aren't supported|
|Description||Right now we rely on X.509 for the authentication of the merchant / Web shop. There should be a way to have certificates for merchant public keys.|
|Tags||No tags attached.|
|related to||0005129||confirmed||suggest to the appropriate standard(s) to add certificate information to XMLHttpRequest|
A few relevant links:
Proposed X509 extension we would need:
OpenSSL mechanism for arbitrary extensions:
Related configuration sample:
Fun ahead, I've PM'ed Simon for help.
Simon points out that there is a new draft:
Last edited: 2017-06-04 13:47
Using Git master after 5th April 2017 of OpenSSL, one can do:
$ openssl req -out CSR.csr -new -newkey Ed25519 -nodes -keyout private.key -days 365 -subj "/C=ZZ/L=World/stateOrProvinceName=ZZ/O=GNU/OU=Taler/CN=shop.demo.taler.net/emailAddressfirstname.lastname@example.org"
to generate a Ed25519 private key as "private.key" and output the CSR as "CSR.csr". The CSR can be viewed using:
$ openssl req -text -noout -in CSR.csr
1) Need to find/create command to convert private.key to GNUnet format
2) Need to figure out how to combine the Ed25519 CSR or Cert with RSA CSRs or Certs so that the server can return _both_ during SSL KX (as we probably don't want to _just_ use Ed25519 for now).
For the 2nd step, assume some CA did (note: setting up the CA is a bit more involved, and in this case the "unique_subject" option must be set to "no" as we create two certificates for the same subject!):
$ openssl ca -out ED.crt -infiles ED.csr
$ openssl ca -out RSA.crt -infiles RSA.csr
for an Ed25519 and RSA CSR respectively. Then a certificate bundle can be created using:
$ cat RSA.crt ED.crt > BOTH.crt
OpenSSL doesn't support displaying the bundle, but keytool does:
$ keytool -printcert -v -file BOTH.crt
For the wallet, the question that is now there is how to get to the bundle.
Assuming we configure a server to include a Ed25519-CRT (in addition to the RSA CRT for the normal TLS process), we need a WebEx API to access the certificate bundle. Providing such an API seems to have gotten a WONTFIX from Chromium in the past (2011): https://bugs.chromium.org/p/chromium/issues/detail?id=107793
About TODO (1):
$ openssl enc -d -base64 -in private.key -out private.bin
converts the base64 encoding to binary; however, that yields 48 bytes instead of 32 (!). However, I checked and the first 16 bytes are always identical ("2e30 0102 3000 0605 2b03 7065 2204 2004") so they likely just identify the key as Ed25519. So:
$ tail -c 32 private.bin > privateED32.bin
$ gnunet-ecc -x privateED32.bin
prints the *same* HEX-encoded public key as what (for example)
$ openssl req -text -noout -in ED.csr
shows (assuming ED.csr corresponds to private.key).
So we DID get the correct private key file. Hence, combining the notes in this bug report into documentation AND figuring out note 12215 in the wallet will fix this bug!
Firefox *used* to have support to query certificate information about an XMLHttpRequest, but this feature is not accessible anymore since they're dropping the old extension APIs.
Maybe it would be easier to convince Chrome/Firefox to implement this again for WebExtensions in the XMLHttpRequest, since
a) it does not have the code complexity problems mentioned in the thread linked above, since it's read-only access to cert information after the request already happened
b) the XMLHttpRequest in WebExtensions is already more powerful than the one on normal web pages (it allows more cross-origin stuff than normally allowed), so this would be a natural place to add it.
Unfortunately I don't see any other solution, other than getting the merchant certificate information over another channel and not coupling it to the transport cert. We'd then have to check the certificate ourselves, which wouldn't be great of course.
|2016-08-25 17:45||Florian Dold||New Issue|
|2016-08-27 11:48||Christian Grothoff||Severity||minor => feature|
|2016-08-27 11:48||Christian Grothoff||Status||new => confirmed|
|2016-09-05 13:06||Christian Grothoff||Priority||normal => urgent|
|2016-09-05 13:06||Christian Grothoff||Product Version||=> 0.0|
|2016-09-05 13:06||Christian Grothoff||Target Version||=> 0.1|
|2016-09-26 13:48||Christian Grothoff||Target Version||0.1 => 0.2|
|2016-09-29 10:54||Christian Grothoff||Priority||urgent => high|
|2016-10-10 08:37||Christian Grothoff||Target Version||0.2 => 0.4|
|2016-10-25 12:08||Christian Grothoff||Note Added: 0011387|
|2016-10-26 20:00||Christian Grothoff||Note Added: 0011389|
|2017-05-04 22:48||Christian Grothoff||Assigned To||=> Christian Grothoff|
|2017-05-04 22:48||Christian Grothoff||Status||confirmed => assigned|
|2017-06-04 13:14||Christian Grothoff||Note Added: 0012213|
|2017-06-04 13:47||Christian Grothoff||Note Edited: 0012213|
|2017-06-04 14:04||Christian Grothoff||Note Added: 0012214|
|2017-06-04 14:19||Christian Grothoff||Note Added: 0012215|
|2017-06-04 14:45||Christian Grothoff||Note Added: 0012216|
|2017-06-04 14:46||Christian Grothoff||Assigned To||Christian Grothoff => Florian Dold|
|2017-06-04 17:15||Florian Dold||Note Added: 0012217|
|2017-06-06 14:24||Christian Grothoff||Target Version||0.4 => 0.9|
|2020-09-04 12:15||Florian Dold||Priority||high => low|
|2020-10-11 21:19||Christian Grothoff||Relationship added||related to 0005129|
|2022-10-20 11:17||Christian Grothoff||Assigned To||Florian Dold =>|
|2022-10-20 11:17||Christian Grothoff||Status||assigned => acknowledged|
|2022-10-20 11:17||Christian Grothoff||Target Version||0.9 =>|
|2023-04-04 18:00||Florian Dold||Target Version||=> post-1.0|