Skip to content

Commit 57674d7

Browse files
dhh1128dhh1128
authored
Merge pull request hyperledger-indy#734 from kdenhartog/master
updated links and added temporary place holder to share link
2 parents 41c3b91 + b6cd3c5 commit 57674d7

File tree

100 files changed

+9768
-4
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

100 files changed

+9768
-4
lines changed

‎doc/design/005-dkms/DKMS Design and Architecture V3.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -67,11 +67,11 @@ DKMS architecture and DPKI provides the following major benefits:
6767

6868
As a general rule, DKMS requirements are a derivation of CKMS requirements, adjusted for the lack of centralized authorities or systems for key management operations. Evernym’s DKMS team and subcontractors performed an extensive analysis of the applicability of conventional CKMS requirements to DKMS using [NIST Special Publication 800-130: A Framework for Designing Cryptographic Key Management Systems](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-130.pdf). For a summary of the results, see:
6969

70-
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Spreadsheet Based On NIST 800-130](https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/DKMS Requirements Spreadsheet Based On NIST 800-130.pdf)
70+
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Spreadsheet Based On NIST 800-130](https://github.com/hyperledger/indy-sdk/blob/master/doc/design/005-dkms/DKMS%20Requirements%20Spreadsheet%20Based%20On%20NIST%20800-130%20-%20Sheet1.pdf)
7171

72-
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Text Based on NIST 800-130](https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/DKMS Requirements Text Based on NIST 800-130.pdf)
72+
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Text Based on NIST 800-130](https://github.com/hyperledger/indy-sdk/blob/master/doc/design/005-dkms/DKMS%20Requirements%20Text%20Based%20on%20NIST%20800-130.pdf)
7373

74-
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Report - 30 June 2017](https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/DKMS Requirements Report - 30 June 2017.pdf)
74+
* [Evernym HSHQDC-17-C-00018 - DKMS Requirements Report - 30 June 2017](https://github.com/hyperledger/indy-sdk/blob/master/doc/design/005-dkms/DKMS%20Requirements%20Report%20-%2030%20June%202017.pdf)
7575

7676
The most relevant special requirements are highlighted in the following sections.
7777

‎doc/design/005-dkms/README.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -33,5 +33,5 @@ These methods are not exclusive and should be combined with key rotation and rev
3333

3434
1. [Design and architecture](DKMS%20Design%20and%20Architecture%20V3.md)
3535
2. **Public Registry for Agent Authorization Policy**. An identity owner create a policy on the ledger that defines its agents and their authorizations.
36-
Agents while acting on the behalf of the identity owner need to prove that they are authorised. [More details](https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/Agent Authorization Policy.pdf)
36+
Agents while acting on the behalf of the identity owner need to prove that they are authorised. [More details](https://github.com/hyperledger/indy-sdk/blob/master/doc/design/005-dkms/Agent%20Authorization%20Policy.pdf)
3737

‎doc/design/005-dkms/agent-2-agent-proposal.puml‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
@startuml
2+
3+
participant "Client Agent" as Client
4+
participant "Server Agent" as Server
5+
6+
== Transport Layer ==
7+
8+
Client -> Server: Transport layer CurveCP HELLO
9+
note left
10+
Conversation starts with establishing standard CurveCP connection.
11+
12+
Important point is that client must (?) be able to authenticate
13+
endpoint (only endpoint, not server identity) on transport level. Without this
14+
it is quite easy to perform man in the middle attacks. In case of
15+
CurveCP transport key will be part of endpoint. It causes agency-level transport
16+
key related correlation, but CurveCP-PW and DID-TLS proposals have the same
17+
issue if we want to indicate server DID securely. Anyway any IP/DNS based
18+
solutions have exactly same issue.
19+
20+
We can adopt this workflow to use TLS protocol too. Endpoint authentication
21+
can be be performed in different ways:
22+
- Option 1 is just use standard CAA signed cert on the endpoint.
23+
- Option 2 is use self signed cert, store server cert in the Ledger,
24+
and add this cert to client trust chain, but this option have a lot
25+
of potential vulnerabilities.
26+
27+
It can be possible to adopt some TOR like protocol too.
28+
end note
29+
Server <-> Client: Complete transport layer CurveCP Handshake
30+
note left
31+
At this point secure transport connection is established.
32+
We can assume that communication is secure, provides integrity, and endpoint is authenticated.
33+
So Client can send Server DID he wants to communicate without fear of eavesdropping.
34+
end note
35+
36+
== DID Protocol Layer ==
37+
38+
Client -> Server: AGENT_CLIENT_HELLO message
39+
note left
40+
Note this sequence diagram describes DID Protocol over sockets layer, but it can be adopted
41+
to HTTP layer too if we use TLS as transport layer.
42+
43+
Client sends AGENT_HELLO message. It contains the following fields:
44+
- Random nonce (CLIENT_NONCE)
45+
- Server DID he wants to communicate (SERVER_DID)
46+
- Security levels that client accepts (SECURITY_LEVELS). It is bit mask with the following
47+
values for now:
48+
- TRANSPORT. Application messages will be secured only on transport layer.
49+
- APPLICATION. Application messages will be also encrypted by DIDs ed25519 keys.
50+
end note
51+
52+
Server -> Server: Server checks that he owns SERVER_DID
53+
Server -> Server: Server checks that he can accept SECURITY_LEVELS
54+
Server -> Client: AGENT_SERVER_HELLO message
55+
note left
56+
Server sends AGENT_SERVER_HELLO message. It contains the following fields:
57+
- CLIENT_NONCE signed by SERVER_DID (CLIENT_NONCE_SIGNATURE)
58+
- Random nonce (SERVER_NONCE)
59+
- Accepted security level (SECURITY_LEVEL). One of value from SECURITY_LEVELS bitmask.
60+
end note
61+
62+
Client -> Client: Client verifies CLIENT_NONCE_SIGNATURE and authenticates Server
63+
Client -> Server: AGENT_CLIENT_ACCEPTED message
64+
note left
65+
Client sends AGENT_CLIENT_ACCEPTED message. It contains the following fields:
66+
- Client DID (CLIENT_DID)
67+
- SERVER_NONCE signed by CLIENT_DID (SERVER_NONCE_SIGNATURE)
68+
end note
69+
70+
Server -> Server: Server verifies SERVER_NONCE_SIGNATURE and authenticates Client
71+
Server -> Client: AGENT_SERVER_ACCEPTED message
72+
note left
73+
Server sends AGENT_SERVER_ACCEPTED message without payload.
74+
75+
At this point Client and Server authenticated each other and performed Nonce Exchange.
76+
They are ready to exchange application-specific messages. This messages can be optionally
77+
encrypted by DIDs ed25519 keys.
78+
end note
79+
80+
== Application Layer ==
81+
82+
Client -> Server: Application layer message 1 (optionally encrypted by Server DID ed25519 key and CLIENT_NONCE)
83+
Server -> Client: Application layer message 1 ack (optionally encrypted by Client DID ed25519 key and SERVER_NONCE)
84+
85+
@enduml

‎doc/design/005-dkms/before-and-after.png‎

52.9 KB
Loading

‎doc/design/005-dkms/cd-pipeline.puml‎

Lines changed: 142 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,142 @@
1+
@startuml
2+
3+
start
4+
5+
title Indy SDK CI/CD Pipeline structure
6+
scale 0.8
7+
8+
partition Testing {
9+
fork
10+
partition "Ubuntu Testing" {
11+
:Start test pool;
12+
if (BRANCH_NAME in ["master", "rc"]) then (yes)
13+
:<b>Libindy\nRelease build;
14+
else (no)
15+
:<b>Libindy\nDebug build;
16+
endif
17+
:<b>Libindy
18+
Testing;
19+
:<b>Python Wrapper
20+
Testing;
21+
:<b>Java Wrapper
22+
Testing;
23+
}
24+
fork again
25+
partition "RHEL Testing" {
26+
:Start test pool;
27+
if (BRANCH_NAME in ["master", "rc"]) then (yes)
28+
:<b>Libindy\nRelease build;
29+
else (no)
30+
:<b>Libindy\nDebug build;
31+
endif
32+
:<b>Libindy
33+
Testing;
34+
:<b>Python Wrapper
35+
Testing;
36+
:<b>Java Wrapper
37+
Testing;
38+
}
39+
fork again
40+
partition "Windows Testing" {
41+
:Start test pool;
42+
if (BRANCH_NAME in ["master", "rc"]) then (yes)
43+
:<b>Libindy\nRelease build;
44+
else (no)
45+
:<b>Libindy\nDebug build;
46+
endif
47+
:<b>Libindy
48+
Testing;
49+
:<b>Python Wrapper
50+
Testing;
51+
:<b>Java Wrapper
52+
Testing;
53+
#red:<b>.Net Wrapper
54+
Testing;
55+
note right: Not implemented yet\nSee IS-257
56+
}
57+
fork again
58+
partition "MacOS Testing" {
59+
#red::Skip;
60+
note right: Not implemented yet\nSee IS-192
61+
}
62+
fork again
63+
partition "iOS Testing" {
64+
#red::Skip;
65+
note right: Not implemented yet\nSee IS-189
66+
}
67+
end fork
68+
}
69+
70+
partition Publishing {
71+
if (BRANCH_NAME in ["master", "rc"]) then (yes)
72+
fork
73+
partition "Ubuntu Publishing" {
74+
:<b>Libindy
75+
Build and publish Master/RC debs;
76+
:<b>Python Wrapper
77+
Publish RC to PyPi;
78+
:<b>Java Wrapper
79+
Build and publish Master/RC to Maven Central;
80+
}
81+
fork again
82+
partition "RHEL Publishing" {
83+
:<b>Libindy
84+
Build and publish Master/RC rpms;
85+
}
86+
fork again
87+
partition "Windows Publishing" {
88+
:<b>Libindy
89+
Build and publish Master/RC dlls archive;
90+
#red:<b>.Net Wrapper
91+
Master/RC Publishing;
92+
note right: Not implemented yet\nSee IS-306
93+
}
94+
fork again
95+
partition "MacOS Publishing" {
96+
#red::Skip;
97+
note right: Not implemented yet\nSee IS-6
98+
}
99+
fork again
100+
partition "iOS Publishing" {
101+
#red::Skip;
102+
note right: Not implemented yet\nSee IS-100
103+
}
104+
end fork
105+
else (no)
106+
:<b>Skip publishing;
107+
endif
108+
}
109+
110+
partition "Acceptance Testing" {
111+
if (BRANCH_NAME == "rc") then (yes)
112+
:Notify QA about new artifacts to test;
113+
:Acceptance testing by QA;
114+
else (no)
115+
:<b>Skip Acceptance Testing;
116+
endif
117+
}
118+
119+
partition "Releasing" {
120+
if (BRANCH_NAME == "rc" && Acceptance tests passed) then (yes)
121+
:<b>Libindy
122+
Move RC debs to Stable repo;
123+
:<b>Libindy
124+
Move RC rmps to Stable repo;
125+
:<b>Libindy
126+
Move RC dlls archive to Stable repo;
127+
:<b>Python Wrapper
128+
Publish Stable to PyPi;
129+
:<b>Java Wrapper
130+
Build and publish Stable to Maven Central;
131+
else (no)
132+
:<b>Skip Releasing;
133+
endif
134+
}
135+
136+
partition Notification {
137+
:Notify team about pipeline result;
138+
}
139+
140+
stop
141+
142+
@enduml

‎doc/design/005-dkms/cd-pipeline.svg‎

Lines changed: 155 additions & 0 deletions
Loading

0 commit comments

Comments
 (0)