View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004629Talerotherpublic2016-08-25 17:452024-08-12 09:53
ReporterFlorian Dold Assigned To 
PrioritylowSeverityfeatureReproducibilityhave not tried
Status acknowledgedResolutionopen 
Product Version0.0 
Target Versionpost-2.0 
Summary0004629: certificates for merchant public keys aren't supported
DescriptionRight 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.
TagsNo tags attached.

Relationships

related to 0005129 confirmed suggest to the appropriate standard(s) to add certificate information to XMLHttpRequest 

Activities

Christian Grothoff

2016-10-25 12:08

manager   ~0011387

A few relevant links:

Proposed X509 extension we would need:
https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00

OpenSSL mechanism for arbitrary extensions:
https://www.openssl.org/docs/manmaster/apps/x509v3_config.html

Related configuration sample:
http://www.mail-archive.com/openssl-users@openssl.org/msg58525.html

Fun ahead, I've PM'ed Simon for help.

Christian Grothoff

2016-10-26 20:00

manager   ~0011389

Simon points out that there is a new draft:


https://tools.ietf.org/html/draft-ietf-curdle-pkix-01

Christian Grothoff

2017-06-04 13:14

manager   ~0012213

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/emailAddress=ssladmin@taler.net"

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

TODO:
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).

Christian Grothoff

2017-06-04 14:04

manager   ~0012214

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

Christian Grothoff

2017-06-04 14:19

manager   ~0012215

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

Christian Grothoff

2017-06-04 14:45

manager   ~0012216

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

Then

$ 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!

Florian Dold

2017-06-04 17:15

manager   ~0012217

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.

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/How_to_check_the_secruity_state_of_an_XMLHTTPRequest_over_SSL

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.

Issue History

Date Modified Username Field Change
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
2024-08-12 09:53 Christian Grothoff Target Version post-1.0 => post-2.0