Design Elements » History » Version 4
Suravi Regmi, 11/21/2025 07:32 PM
| 1 | 1 | Suravi Regmi | # Design Elements |
|---|---|---|---|
| 2 | This is the technical reference section. |
||
| 3 | 4 | Suravi Regmi | |
| 4 | ### **[[Naming_Scheme|Naming Scheme]]** |
||
| 5 | 1 | Suravi Regmi | Stream naming hierarchy (include diagram from paper) |
| 6 | Data naming: |
||
| 7 | /org/md2k/.../DATA/<timestamp> |
||
| 8 | |||
| 9 | Attribute names (/org/md2k/ATTRIBUTE/...) |
||
| 10 | |||
| 11 | Manifest naming (.../MANIFEST/<seq>) |
||
| 12 | |||
| 13 | CK naming conventions |
||
| 14 | |||
| 15 | DKEY naming conventions |
||
| 16 | |||
| 17 | PUBPARAMS naming |
||
| 18 | |||
| 19 | |||
| 20 | 2 | Suravi Regmi | ### Trust Model |
| 21 | 1 | Suravi Regmi | |
| 22 | Trust anchor |
||
| 23 | |||
| 24 | Component identities |
||
| 25 | |||
| 26 | Cert verification |
||
| 27 | |||
| 28 | Signing chain |
||
| 29 | |||
| 30 | What each module verifies |
||
| 31 | |||
| 32 | ### Access Control + Policy Structure |
||
| 33 | |||
| 34 | New policy structure (requester, allow/deny filters) |
||
| 35 | |||
| 36 | Example policy with evolution from old → new format |
||
| 37 | |||
| 38 | Filter semantics |
||
| 39 | |||
| 40 | Mapping to attributes |
||
| 41 | |||
| 42 | 2 | Suravi Regmi | ### NAC-ABE Design |
| 43 | 1 | Suravi Regmi | |
| 44 | Why KP-ABE |
||
| 45 | |||
| 46 | Data encryption → CK encryption → CK decryption |
||
| 47 | |||
| 48 | ABE encryption of CK (black box) |
||
| 49 | |||
| 50 | ABE key issuance (DKEY) |
||
| 51 | |||
| 52 | CK granularity (second/minute/hour) |
||
| 53 | |||
| 54 | Tradeoffs of CK reuse level |
||
| 55 | |||
| 56 | 2 | Suravi Regmi | ### Manifest Design |
| 57 | 1 | Suravi Regmi | |
| 58 | Why manifests exist |
||
| 59 | |||
| 60 | Manifest format (full data names + digest) |
||
| 61 | |||
| 62 | Creation triggers: count/time threshold |
||
| 63 | |||
| 64 | Sequential numbering scheme |
||
| 65 | |||
| 66 | How manifests replace per-data sync announcements |
||
| 67 | |||
| 68 | 2 | Suravi Regmi | ### PSync Design |
| 69 | 1 | Suravi Regmi | |
| 70 | Why PSync is used |
||
| 71 | |||
| 72 | How the sync list works conceptually |
||
| 73 | |||
| 74 | Manifest announcement via PSync |
||
| 75 | |||
| 76 | Differences from classical pub-sub |
||
| 77 | |||
| 78 | Limitations / assumptions |
||
| 79 | |||
| 80 | Boundaries (MGuard-specific usage, not raw PSync theory) |
||
| 81 | |||
| 82 | ### Pub-Sub API Design (MGuard Perspective) |
||
| 83 | |||
| 84 | Producer API: publish() |
||
| 85 | |||
| 86 | Consumer API: subscribe() |
||
| 87 | |||
| 88 | Callback delivery |
||
| 89 | |||
| 90 | Reliability guarantees |