Page 2 of 3
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Fri Nov 21, 2014 9:59 am
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.
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Fri Nov 21, 2014 11:28 am
by renne
I've found
Domain Name Specification and
Identity in the Wiki.
Where do I create an entry for a generic application?
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sat Nov 22, 2014 9:15 am
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) {}
Please comment!
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sat Nov 22, 2014 9:59 am
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?
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sat Nov 22, 2014 11:18 am
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.
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sat Nov 22, 2014 8:18 pm
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.
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sun Nov 23, 2014 2:56 pm
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.
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sun Nov 23, 2014 3:34 pm
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
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sun Nov 23, 2014 3:59 pm
by biolizard89
I agree with Daniel that application-specific features do not belong in namecoind or libcoin.
Re: BTLS: Blockchain-based Transport Layer Security
Posted: Sun Nov 23, 2014 6:00 pm
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.