View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002252 | GNUnet | GNS | public | 2012-04-02 13:23 | 2012-06-18 23:36 |
| Reporter | schanzen | Assigned To | schanzen | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | won't fix | ||
| Summary | 0002252: Multi label delegations and records not supported | ||||
| Description | Multi label names in a zone are not supported by the resolver. If the resolver encounters a label it will try to delegate (find a PKEY) for it. Only if a single label (or none) is left it will try to resolve the actual queried record type. In theory multi label names should be supported. However they will interfere greatly with the UX and the network performance. Network Performance: for a given name for resolution (a.b.c.gnunet) the resolver needs to query, in parallel, c, b.c and a.b.c for delegation. A misconfigured zone could lead to multiple results here and it is not (yet) determined what PKEY would take precedence. Same applies for record lookup. Also the parallel lookup would not so much affect the namestore but the DHT performance. UX: In the zone editor say you have a PKEY for "bob". Now if you enter a record or delegation for "a.bob" it will either _hide_ "bob" or "bob" will hide "a.bob" depending on the implementation. In other words this should not be allowed. But where is this enforced? Different approach: If we say that multi label delegation is not allowed we have to enforce this in the namestore. Then if a user wants to have a subdomain "bob" he needs a second key pair (zone) for it. i.e. User A wants the name "www.bob" -> he needs a PKEY for "bob" that is not his root zone and can then add www record into this zone. this introduces issues with the zone editor UI and the GNS daemon. First the UI does not allow you to do this and cannot display this properly. The GNS daemon on the other hand can not really determine the zone's that belong to the user. But it needs to know for DHT propagation and zone transfers! (could be resolved via cfg entries or namestore flags but the key management is the big issue here as we do not really want the user to deal with >1 keys) | ||||
| Tags | No tags attached. | ||||
|
|
Just an idea: Maybe just "expose" a single key pair to the user. Then if the user wanto to "subdelegate" we just derive further private keys depending on the name to subdelegate. For simplification I assume a single subdomain: a.b.gnunet there is no b pkey in the namestore. If there is namestore will not create the record. 1. First derive a new private key Kp' from the original root zone key Kp (provided on record_create) 2. Put a into the "new" subzone H(Kpub') 3. Put b into zone H(Kpub) as PKEY -> resolution possible. The issue that is still pending then is how we differentiate between "our" PKEYs and foreign delegation. Maybe an additional record flag? |
|
|
I'm not sure I like that idea of 'derived' keys. I think managing >1 key is fine, the GNS service will sooner rather than later have to deal with that anyway (multi-user support!). All I think we'll need is that the GUI detects that the private key that we delegate to is under our own control, it can then do the right thing (TM) with tree-structure and everything. And to create such a sub-zone, we just need to automatically create a fresh key pair and store it in an appropriate location (where we can find it). I think that's a clean way to do it. |
|
|
I think this "issue" is inherently not compatible with the current approach. Close as wontfix? |
|
|
Sounds good. Still you should discuss this design choice / issue in your thesis. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-04-02 13:23 | schanzen | New Issue | |
| 2012-04-02 13:23 | schanzen | Status | new => assigned |
| 2012-04-02 13:23 | schanzen | Assigned To | => schanzen |
| 2012-04-02 20:26 | schanzen | Note Added: 0005685 | |
| 2012-04-03 01:13 | Christian Grothoff | Note Added: 0005686 | |
| 2012-05-03 01:21 | Christian Grothoff | Product Version | => Git master |
| 2012-05-03 01:21 | Christian Grothoff | Target Version | => 0.9.4 |
| 2012-06-18 23:28 | schanzen | Note Added: 0006097 | |
| 2012-06-18 23:36 | Christian Grothoff | Note Added: 0006099 | |
| 2012-06-18 23:36 | Christian Grothoff | Status | assigned => closed |
| 2012-06-18 23:36 | Christian Grothoff | Resolution | open => won't fix |
| 2012-06-18 23:36 | Christian Grothoff | Product Version | Git master => |
| 2012-06-18 23:36 | Christian Grothoff | Target Version | 0.9.4 => |
