BTLS: Blockchain-based Transport Layer Security

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BTLS: Blockchain-based Transport Layer Security

Post by domob »

renne wrote:
renne wrote:In my opinion this is an unnecessary redundancy. As blockchains are decentralized we should drop the idea of the hierarchical client/server paradigm and consider each user/client/server as an equal node. We only need the client/server language to explain it to the IT-dinosaurs! ;)
@domob: What do you think?
I still think that it is a different thing to say "this is a general certificate that I may be using for email, chatting or whatever" (the "x.509" key) and to say "this certificate is allowed to authenticate me as id/myname" (the "signer" key). But I think you should just move forward with the general definition of the X.509 spec. Discussions about where exactly to use it later on can then follow.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

I've found Domain Name Specification and Identity in the Wiki.
Where do I create an entry for a generic application?

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

Two new suggestions:
  • Instead of a button per identity in the "Manage Names" table I suggest the options "Create and add/replace client certificate" and "Delete client certificate" in the context menu per identity as we need to disable/delete a client certificate when compromised or lost.
    libcoin: Add method

    Code: Select all

    bool verifyX509Certificate(wchar_t *subject_common_name, int8u scn_length, wchar_t *fingerprint, int16u fp_length) {}
    to simplify interfacing with verifying applications (e.g. TLS server).
Please comment! ;)

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

I just considered to use the certificate public key instead of the fingerprint as it would allow new encrypted transport protocols to use the public key directly without an unencrypted certificate handshake.

But I assume this would bloat the blockchain and have negative scaling effects ...?

What do you think?
Last edited by renne on Sat Nov 22, 2014 11:41 am, edited 1 time in total.

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

Using

Code: Select all

bool verifyCertificate(X509 *certificate) {}
in libcoin would allow us to adjust the dataset/verification process without breaking API-compatibility with verifying applications. If a public key is used for verification it would be a simple comparison with the blockchain. If a fingerprint is used we would have to derive the hashing algorithm from the signing algorithm, create the fingerprint and compare it to the blockchain.

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: BTLS: Blockchain-based Transport Layer Security

Post by domob »

renne wrote:Using

Code: Select all

bool verifyCertificate(X509 *certificate) {}
in libcoin would allow us to adjust the dataset/verification process without breaking API-compatibility with verifying applications. If a public key is used for verification it would be a simple comparison with the blockchain. If a fingerprint is used we would have to derive the hashing algorithm from the signing algorithm, create the fingerprint and compare it to the blockchain.
I think that this (X.509 certificates as you propose) is outside of the scope of namecoind/libcoin. Instead, it should be done in NMControl or a custom higher-level application based on namecoind/libcoin. But that's just my opinion, others may see it differently.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by biolizard89 »

domob wrote:
renne wrote:Using

Code: Select all

bool verifyCertificate(X509 *certificate) {}
in libcoin would allow us to adjust the dataset/verification process without breaking API-compatibility with verifying applications. If a public key is used for verification it would be a simple comparison with the blockchain. If a fingerprint is used we would have to derive the hashing algorithm from the signing algorithm, create the fingerprint and compare it to the blockchain.
I think that this (X.509 certificates as you propose) is outside of the scope of namecoind/libcoin. Instead, it should be done in NMControl or a custom higher-level application based on namecoind/libcoin. But that's just my opinion, others may see it differently.
If it produces data that needs to be written to a name value, then that would require modifications to NMControl to allow write operations. I'm not necessarily opposed to that, but it would require careful thought.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

biolizard89 wrote:If it produces data that needs to be written to a name value, then that would require modifications to NMControl to allow write operations. I'm not necessarily opposed to that, but it would require careful thought.
Only Namecoin needs to register the fingerprint of the X.509 certificate in the blockchain once after creation. All other applications (e.g. a SSL/TLS-server) just query the blockchain for the tupel <name>:<fingerprint> for verification purpose. My idea was to add a method to libcoin which encapsulates the certificate verification (abstraction layer) by checking Common Name and fingerprint of the X.509 certificate against the blockchain. That way we can change the blockchain specification without breaking applications. Using NMControl isn't such a good idea as applications (e.g. STunnel) will need a C/C++ library and admins won't install extra software. Consider a webserver (https) with thousands of requests per second using NMControl ... down ... down ... down ...

Code: Select all

Namecoin(d) |                              | libcoin      |             | Application
creates and |  ----->  Blockchain  <-----  | verifies     |   <-----    | requests
registers   |                              | certificate  |             | certificate
certificate |                              |              |             | verification

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by biolizard89 »

I agree with Daniel that application-specific features do not belong in namecoind or libcoin.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

renne
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

Re: BTLS: Blockchain-based Transport Layer Security

Post by renne »

I've hacked together example code to generate a self-signed X.509 client-certificate. It needs a lot of love (charset, catching errors, ...) but it produces a X.509 certificate in PKCS12 file-format which can be imported into Firefox. I also prints the sha256-fingperprint of the certificate. Namecoin(d) only needs to add/replace an application record in the blockchain.
Attachments
mkcert.c
Example code creating self-signed X.509 client-certificate for authentication against the Namecoin blockchain.
(4.7 KiB) Downloaded 302 times

Post Reply