Namecoin as Root-CA for .bit-domains/identities

[domob]

In which format is the private key returned by "dumpprivkey" encoded?

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.

[phelix]

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?

[renne]

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?

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.

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)?

[somename]

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?

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.

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)?

Can you use CORS (http://enable-cors.org/server_nginx.html) or setup a local Web proxy with CORS allowed?

[renne]

Can you use CORS (http://enable-cors.org/server_nginx.html) or setup a local Web proxy with CORS allowed?

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.

[phelix]

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?

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.

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.

Are identities/domains and wallets strict 1:1-relations or is it possible to assign multiple identities/domains to one wallet?

You can have multiple names in a wallet. Even multiple names in one address though there are some privacy/security implications.

[biolizard89]

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?

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.

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)?

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]

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?

Yes.

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.

[biolizard89]

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?

Yes.

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.

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]

You can create as many different X.509 server- or S/MIME-certificates for a <name> as you want. Each one will have a unique RSA key-pair and the X.509 server- or S/MIME-certificate itself will be signed with the private key of the corresponding blockchain wallet. After creation you just install the server-certificates on your servers (e.g. Apache) and the S/MIME-certificates in your applications (e.g. Firefox). The X.509 server- or S/MIME-certificates are valid until "notAfter" expires or the <name> (e.g. identity|.bit-domain) is removed from the blockchain wallet. Removing the <name> from the blockchain wallet revokes ALL X.509 server- or S/MIME-certificates created for the <name>:<wallet> combination. If X.509 server- or S/MIME-certificates are compromised you revoke them by transferring the <name> to another wallet.

There are only two key pairs involved:

• X.509 server- or S/MIME-certificates: RSA key-pair to authenticate/exchange stream ciphers in applications
  Blockchain: ECDSA wallet key-pair to sign the X.509 server- or S/MIME-certificates

The hierarchy:

Blockchain (replaces Certificate Authorities)
|
X.509 server- or S/MIME-certificates

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?

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.
If you want to change the wallet keys you create the new X.509 server- or S/MIME-certificates signed with the private ECDSA key of a new wallet, install them into your applications and transfer the <name> to the new wallet. All certificates of the old <name>:<wallet>-combination are revoked automagically.

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

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.

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.

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.

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.

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