The first secure, decentralized, human-meaningful naming system.
https://forum.namecoin.org/
The same as Bitcoin's "WIF", except for a different magic constant. You should be able to find plenty of documentation of it. Roughly speaking, it is 32 bytes of entropy (which, as far as I know, represent the private key as scalar for EC maths) plus a checksum encoded in Base58.renne wrote:In which format is the private key returned by "dumpprivkey" encoded?
Having a certificate per identity/domain in the blockchain would bloat the blockchain a lot. The idea is to sign a server- or S/MIME-certificate with the private ECDSA-key of the wallet. Any validator just queries the public ECDSA-key of an identity/domain from the blockchain und checks the signature of the server- or S/MIME-certificate with that public ECDSA-key.phelix wrote:Would it not be easier to locally create a certificate and add it as a root certificate to the system so that it can be used to authenticate all https .bit requests?
Can you use CORS (http://enable-cors.org/server_nginx.html) or setup a local Web proxy with CORS allowed?renne wrote:Having a certificate per identity/domain in the blockchain would bloat the blockchain a lot. The idea is to sign a server- or S/MIME-certificate with the private ECDSA-key of the wallet. Any validator just queries the public ECDSA-key of an identity/domain from the blockchain und checks the signature of the server- or S/MIME-certificate with that public ECDSA-key.phelix wrote:Would it not be easier to locally create a certificate and add it as a root certificate to the system so that it can be used to authenticate all https .bit requests?
Are identities/domains and wallets strict 1:1-relations or is it possible to assign multiple identities/domains to one wallet?
I'm currently stuck with Cross-Site-Scripting. Firefox loads my HTML-file as a tab, but when I try to access Namecoin at http://127.0.0.1:8336 via a XMLHTTPRequest Firefox creates the error message "NS_ERROR_DOM_BAD_URI: Access to restricted URI denied". Does anyone have an idea how to solve this besides .htaccess (which is not possible with a local file)?
No. It's a HTML5-file with JS on the local disk and opened via "file://". I'm trying to connect to "http://127.0.0.1:8336" to communicate with Namecoind.somename wrote:Can you use CORS (http://enable-cors.org/server_nginx.html) or setup a local Web proxy with CORS allowed?
I meant for the certificates to be generated on the fly from blockchain data and be accepted by the browser through the locally created "root" certificate.renne wrote:Having a certificate per identity/domain in the blockchain would bloat the blockchain a lot. The idea is to sign a server- or S/MIME-certificate with the private ECDSA-key of the wallet. Any validator just queries the public ECDSA-key of an identity/domain from the blockchain und checks the signature of the server- or S/MIME-certificate with that public ECDSA-key.phelix wrote:Would it not be easier to locally create a certificate and add it as a root certificate to the system so that it can be used to authenticate all https .bit requests?
You can have multiple names in a wallet. Even multiple names in one address though there are some privacy/security implications.Are identities/domains and wallets strict 1:1-relations or is it possible to assign multiple identities/domains to one wallet?
Do I understand correctly that your scheme would require a name to stay at the same Namecoin owner address in order to keep the same TLS cert? Reusing owner addresses will harm privacy, and also makes quantum attacks easier.renne wrote:Having a certificate per identity/domain in the blockchain would bloat the blockchain a lot. The idea is to sign a server- or S/MIME-certificate with the private ECDSA-key of the wallet. Any validator just queries the public ECDSA-key of an identity/domain from the blockchain und checks the signature of the server- or S/MIME-certificate with that public ECDSA-key.phelix wrote:Would it not be easier to locally create a certificate and add it as a root certificate to the system so that it can be used to authenticate all https .bit requests?
Are identities/domains and wallets strict 1:1-relations or is it possible to assign multiple identities/domains to one wallet?
I'm currently stuck with Cross-Site-Scripting. Firefox loads my HTML-file as a tab, but when I try to access Namecoin at http://127.0.0.1:8336 via a XMLHTTPRequest Firefox creates the error message "NS_ERROR_DOM_BAD_URI: Access to restricted URI denied". Does anyone have an idea how to solve this besides .htaccess (which is not possible with a local file)?
Yes.biolizard89 wrote:Do I understand correctly that your scheme would require a name to stay at the same Namecoin owner address in order to keep the same TLS cert?
Hmm.... how is key rotation handled? Let's say I want to change keys for whatever reason -- does that mean that under your scheme, I will have to change my server's TLS cert exactly when the blockchain adds the block with my name_update, or can I have more than one key at a time? I assume you're aware that standard Namecoin addresses pay to a public key hash rather than a public key -- there's nothing preventing use of a public key in the blockchain, but it's not commonly done in Bitcoin or Namecoin (I suppose as long as the public key of the CA is revealed by the server's cert chain, this isn't actually an issue - just want to make sure you're taking this into consideration). I would be worried about cross-protocol attacks as well, given that the same ECC key is signing both Namecoin transactions and X.509 certs. Other issue would be that a Namecoin d/ name can have multiple addresses associated with it -- the owner of the d/ name, the owners of any imported dd/ names, and (in the future) possibly the delegated renewal addresses of the d/ and dd/ names. What would be the mechanism of choosing which addresses are valid keys of the CA? Would it make sense to have a JSON field that contains a Namecoin name, which specifies which Namecoin name's pubkey is used for TLS? That shouldn't add much extra blockchain bloat, I think.renne wrote:Yes.biolizard89 wrote:Do I understand correctly that your scheme would require a name to stay at the same Namecoin owner address in order to keep the same TLS cert?
The X.509 server- or S/MIME-certificate is generated with the <identity|.bit-domain> as CommonName, own private/public key-pair and signed with the private ECDSA-key of the blockchain wallet. Currently I'm working on a HTML5-flatfile app which will create the X.509 server- or S/MIME-certificates. The validation process (e.g. TLS) will check the consistency of a X.509 server- or S/MIME-certificate as usual (timestamps, ..). Instead of validating against a certificate-chain the validation process will query the public ECDSA-key of the blockchain wallet corresponding to the identity/.bit-domain and validate the signature of the X.509 server- or S/MIME certificate with that public ECDSA-key. If the signature of the X.509 server- or S/MIME-certificate cannot be validated because the tuple <identity-|.bit-domain-wallet ECDSA public key>:<signature private key> does not match, the X.509 server- or S/MIME-certificate is invalid. Transferring the <identity|.bit-domain> to another blockchain-wallet invalidates the X.509 server- or S/MIME-certificate. A new one has to be created. If one doesn't want to be connected to other information in the blockchain he has to assign one <identity|.bit-domain> to one blockchain wallet. n:1- or n:m-relations have to be avoided. That way it is possible to create X.509 server- or S/MIME-certificates without any write-operations on the blockchain or bloating the blockchain by e.g. public keys of certificates.
If you set the "notAfter"-value of the X.509 server- or S/MIME-certificates to e.g. 3 month + 2 weeks they will expire after 3 month + 2 weeks and you can add new X.509 server- or S/MIME-certificates to your applications every three month. That way the certificates will overlap for two weeks.biolizard89 wrote:Hmm.... how is key rotation handled? Let's say I want to change keys for whatever reason -- does that mean that under your scheme, I will have to change my server's TLS cert exactly when the blockchain adds the block with my name_update, or can I have more than one key at a time?
As long as a X.509-validator is somehow able to retrieve the public ECDSA key of the wallet from the blockchain everything is fine.biolizard89 wrote:I assume you're aware that standard Namecoin addresses pay to a public key hash rather than a public key -- there's nothing preventing use of a public key in the blockchain, but it's not commonly done in Bitcoin or Namecoin (I suppose as long as the public key of the CA is revealed by the server's cert chain, this isn't actually an issue - just want to make sure you're taking this into consideration).
It reduces complexity in applications and for users which increases security a lot (e.g. programming errors, misunderstanding of concept). In long term it may be reasonable to fork the monetary service and the authentication service into separate blockchains.biolizard89 wrote:I would be worried about cross-protocol attacks as well, given that the same ECC key is signing both Namecoin transactions and X.509 certs.
I think it's possible to sign a X.509-certificate with multiple private keys. The validator-specification has to be bijective about which wallets/namespaces supersede others (maybe even with timestamp-conditions for temporary owner-ship).biolizard89 wrote:Other issue would be that a Namecoin d/ name can have multiple addresses associated with it -- the owner of the d/ name, the owners of any imported dd/ names, and (in the future) possibly the delegated renewal addresses of the d/ and dd/ names. What would be the mechanism of choosing which addresses are valid keys of the CA? Would it make sense to have a JSON field that contains a Namecoin name, which specifies which Namecoin name's pubkey is used for TLS? That shouldn't add much extra blockchain bloat, I think.