[ADR] 0004 - Separate Transport and Application Keys #35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bryanchriswhite
added
p2p
architecture decision
bryanchriswhite
changed the title
bryanchriswhite
force-pushed
the
docs/ADR0004
branch
from
72261de to
753cbe6
Compare
bryanchriswhite
requested review from
Olshansk,
okdas,
dylanlott and
gokutheengineer
Olshansk
requested changes
Apr 28, 2023
This was referenced May 14, 2023
|
@bryanchriswhite Bump. Wanted to point attention to this comment specifically: #35 (comment) |
bryanchriswhite
force-pushed
the
docs/ADR0004
branch
from
0507fe8 to
7f3b0a5
Compare
bryanchriswhite
force-pushed
the
docs/ADR0004
branch
from
7f3b0a5 to
383f43a
Compare
bryanchriswhite
changed the title
bryanchriswhite
changed the title
Olshansk
requested changes
May 22, 2023
Comment on lines
36
to
40
| - Security: Minimizing the risks associated with key compromise | ||
| - Simplification: Reducing complexity in identity management | ||
| - Flexibility: Allowing different key management strategies for different modules | ||
| - Isolation: Minimizing the impact of compromise on other system components | ||
| - Optionality: Enabling future changes and extensions to the protocol |
There was a problem hiding this comment.
NIT: Bold the words used for driving the decision.
Ditto elsewhere where applicable
| 1. Use a single private key for both P2P and other functionalities | ||
| 2. Use separate private keys for P2P and other functionalities | ||
|
|
||
| ## Decision Outcome |
There was a problem hiding this comment.
There is no mention of things like:
- TLS
- Networking key rotation
- The fact that "utility" keys are tied to the actor's stake/earnings/utility (e.g. think Applications, Servicres) but P2P is primarily used for networking and security
- What's automatic or manual for a user (e.g. P2P key rotation can be automated)
- Some pubKeys corresponding to privKeys are stored on-chain while others are not
Co-authored-by: Daniel Olshansky <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This pull request adds an Architecture Decision Record (ADR) proposing the use of separate private keys for the transport and consensus layers in the system. The ADR discusses the context, decision drivers, considered options, and the pros and cons of each option, ultimately recommending the use of separate private keys.
The chosen option is to keep the P2P and consensus private keys separate. By using separate private keys, the system can achieve better security, flexibility, and isolation in the event of key compromise. The ADR will also serve as a reference for future discussions or changes related to key management in the system.
Please review the ADR and provide feedback on:
Once the ADR has been reviewed and revised as necessary, it will be merged into the repository to serve as a reference for the project.
Related Issue