In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.
https://github.com/ChristopherA/revocab ... cates-hack
REQUEST FOR COMMENTS (literally): The d/ specification
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
Re: REQUEST FOR COMMENTS (literally): The d/ specification
There is a difference though: a name can't be revoked once it's stolen whereas with Allen's method you only need a copy of the key to do so.biolizard89 wrote:In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.
https://github.com/ChristopherA/revocab ... cates-hack
Translated to Namecoin it would mean this: If a name moves to another address it is revoked. IMHO this is worth pondering on.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
I actually brought this up a while back, see https://forum.namecoin.info/viewtopic.php?f=5&t=2226phelix wrote:There is a difference though: a name can't be revoked once it's stolen whereas with Allen's method you only need a copy of the key to do so.biolizard89 wrote:In Namecoin, to revoke a TLS cert, you remove its fingerprint from your name. The changes will usually propagate worldwide in about 40 minutes (10 minutes for a Namecoin block; 30 minutes for NMControl's cache to clear). I think it is possible to reduce that from 40 minutes to about 10 seconds via a combination of accepting unconfirmed name operations (which are safe), and smarter NMControl cache handling.johnc wrote:Not sure if related, but how does NMC handles TLS revocations?
This guy is working on that and i think it could very well either use namecoin or give his opinion.
https://github.com/ChristopherA/revocab ... cates-hack
Translated to Namecoin it would mean this: If a name moves to another address it is revoked. IMHO this is worth pondering on.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: REQUEST FOR COMMENTS (literally): The d/ specification
@Daniel, you should look at the "import" part of the spec, as it differs from the spec that we partially implemented for NMControl (and it has an effect on the id/ namespace, specifically saying that "import" is no longer namespace-agnostic).domob wrote:I'm also for IDN. If there are security concerns, the browser should handle them adequately (disallowing mixed script or even displaying the xn-- literally in case of paranoid users). I have no opinion on the draft apart from that, since I'm not a DNS or d/ expert.
@Hugo, a few more comments:
I would like the "import" spec description to include some more non-normative examples, particularly of the subdomain selector.
Also, I would like to see an optional third argument to an import, which consists of an array of the fields being imported. E.g. ["ip", "ip6"] would restrict the import to just those two fields (after applying the "import" fields in the imported name) rather than also importing things like TLS fingerprints. A value of ["*"] would be the default, and would import everything.
Finally, we should consider whether we should (possibly as a future revision) limit the "tor" and "i2p" fields to only be permitted to point to Tor and I2P domains that have authorized the d/ name in question (e.g. by signing the d/ name with the .onion key). Both Fabio from GlobaLeaks and Jesse from OnioNS think that this is a highly useful property. I don't want to delay approval of this spec while we figure out the format for such a signature, but if it's something that we even might do in the future, there should be a note in the spec saying that users of "tor" and "i2p" should be aware that the spec may change in a way that will require changes to existing name configurations.