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.renne wrote:@domob: What do you think?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!
BTLS: Blockchain-based Transport Layer Security
Re: BTLS: Blockchain-based Transport Layer Security
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
Re: BTLS: Blockchain-based Transport Layer Security
I've found Domain Name Specification and Identity in the Wiki.
Where do I create an entry for a generic application?
Where do I create an entry for a generic application?
Re: BTLS: Blockchain-based Transport Layer Security
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 methodto simplify interfacing with verifying applications (e.g. TLS server).Code: Select all
bool verifyX509Certificate(wchar_t *subject_common_name, int8u scn_length, wchar_t *fingerprint, int16u fp_length) {}
Re: BTLS: Blockchain-based Transport Layer Security
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?
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.
Re: BTLS: Blockchain-based Transport Layer Security
Using 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.
Code: Select all
bool verifyCertificate(X509 *certificate) {}
Re: BTLS: Blockchain-based Transport Layer Security
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.renne wrote:Usingin 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.Code: Select all
bool verifyCertificate(X509 *certificate) {}
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: BTLS: Blockchain-based Transport Layer Security
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.domob wrote: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.renne wrote:Usingin 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.Code: Select all
bool verifyCertificate(X509 *certificate) {}
Re: BTLS: Blockchain-based Transport Layer Security
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 ...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.
Code: Select all
Namecoin(d) | | libcoin | | Application
creates and | -----> Blockchain <----- | verifies | <----- | requests
registers | | certificate | | certificate
certificate | | | | verification
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: BTLS: Blockchain-based Transport Layer Security
I agree with Daniel that application-specific features do not belong in namecoind or libcoin.
Re: BTLS: Blockchain-based Transport Layer Security
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 317 times