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

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

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

Post by domob » Tue Sep 15, 2015 5:10 am

renne wrote: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.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

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

Post by phelix » Tue Sep 15, 2015 8:17 am

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?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

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

Post by renne » Tue Sep 15, 2015 3:27 pm

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?
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
Posts: 80
Joined: Mon Sep 15, 2014 3:12 pm
os: windows

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

Post by somename » Tue Sep 15, 2015 3:46 pm

renne wrote:
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?
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
Posts: 80
Joined: Fri May 30, 2014 7:09 pm
os: linux

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

Post by renne » Tue Sep 15, 2015 3:59 pm

somename wrote: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
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

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

Post by phelix » Tue Sep 15, 2015 4:00 pm

renne wrote:
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?
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.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

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

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

Post by biolizard89 » Wed Sep 16, 2015 3:04 am

renne wrote:
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?
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.
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: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Thu Sep 17, 2015 7:47 am

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?
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
Posts: 1977
Joined: Tue Jun 05, 2012 6:25 am
os: linux

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

Post by biolizard89 » Thu Sep 17, 2015 8:04 am

renne wrote:
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?
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.
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: Namecoin as Root-CA for .bit-domains/identities

Post by renne » Thu Sep 17, 2015 10:48 am

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

Post Reply