Requirements

On this page, you will learn about:

The quality requirements and constraints that govern the design of the Keychain system.

Quality Requirements and Goals

Requirement Name	Description
R1. Self-sovereign Key Management	Private keys must be managed by the Keychain client and stored on the local device(s).
R2. Data-centric Security	Data should be encrypted and digitally signed in a way that the security guarantees hold regardless of where the data is stored or transmitted.
R3. Automated Key Rollover	The system should allow users to change their application-level keys with turn-key simplicity and automatically communicate the respective public key changes to all relevant counter parties.
R4. Historical Digital Signature Attribution	If a party can attribute and verify a digital signature on certain at a point in time, then the party should continue to perform the same verification for as long as the party has access to the data and the blockchain, even if the period is several decades.
R5. Application-level Consensus	The system must implement application-level Byzantine agreement on the receipt of application data and documents.
R6. Data Backwards Compatibility	All Keychain gateways must be backwards compatible with Keychain generated cipher texts regardless of when, when, or by which gateway the cipher text was produced.
R7. Client Interoperability	System components must inter operate fully with other clients within the same build regardless of the target platform architecture / environment (Windows, Linux, Android, 32-bit/64-bit, etc).
R8. Device Native Support	The Keychain client should run natively from machine instruction set code where possible.
R9. Support for Wide Range of Device Sizes	The Keychain clients must support and effective use resources on a wide range of device hardware, including small, Internet connected ones
R10. Multi-platform Support	The Keychain client must support the major environments (operating systems, 32 and 64 bit, machine architectures and instruction sets).
R11. Integration Readiness	The Keychain client should readily allow deployment into and integration with common corporate networks and allow network teams to continue to follow best practices. For example, network connections should be outbound only for devices that are inside the corporate network, avoiding the need to open inbound network firewall ports. Software servers should operate in network demilitarized zones.
R12. Compatibility with Existing Applications	The full functionality of the Keychain system should be usable within the architectural constraints of existing applications without requiring the users to migrate data and applications onto new architectures.
R13. Idiomatic Application Programming Interfaces	Each Keychain Core SDK interface should be idiomatic of the programming language for which it is written and exhibit best practices for that language.
R14. Obsolescence	Users should have a relatively cheap way to migrate their application to another platform or blockchain. Vendor lock-in should be minimized where possible. The user should be able to migrate data to new formats and migrate certificates to other blockchains or stores.
R15. Scale	The system should support public-key-infrastructure functions for at least single-digit billions of client devices where operation latencies are defined by quality-of-service tiers with reasonable costs.
R16. Privacy	The system should avoid publicly disclosing the relationship between a blockchain certificate and the user.

Requirement Name

Description

R1. Self-sovereign Key Management

Private keys must be managed by the Keychain client and stored on the local device(s).

R2. Data-centric Security

Data should be encrypted and digitally signed in a way that the security guarantees hold regardless of where the data is stored or transmitted.

R3. Automated Key Rollover

The system should allow users to change their application-level keys with turn-key simplicity and automatically communicate the respective public key changes to all relevant counter parties.

R4. Historical Digital Signature Attribution

If a party can attribute and verify a digital signature on certain at a point in time, then the party should continue to perform the same verification for as long as the party has access to the data and the blockchain, even if the period is several decades.

R5. Application-level Consensus

The system must implement application-level Byzantine agreement on the receipt of application data and documents.

R6. Data Backwards Compatibility

All Keychain gateways must be backwards compatible with Keychain generated cipher texts regardless of when, when, or by which gateway the cipher text was produced.

R7. Client Interoperability

System components must inter operate fully with other clients within the same build regardless of the target platform architecture / environment (Windows, Linux, Android, 32-bit/64-bit, etc).

R8. Device Native Support

The Keychain client should run natively from machine instruction set code where possible.

R9. Support for Wide Range of Device Sizes

The Keychain clients must support and effective use resources on a wide range of device hardware, including small, Internet connected ones

R10. Multi-platform Support

The Keychain client must support the major environments (operating systems, 32 and 64 bit, machine architectures and instruction sets).

R11. Integration Readiness

The Keychain client should readily allow deployment into and integration with common corporate networks and allow network teams to continue to follow best practices. For example, network connections should be outbound only for devices that are inside the corporate network, avoiding the need to open inbound network firewall ports. Software servers should operate in network demilitarized zones.

R12. Compatibility with Existing Applications

The full functionality of the Keychain system should be usable within the architectural constraints of existing applications without requiring the users to migrate data and applications onto new architectures.

R13. Idiomatic Application Programming Interfaces

Each Keychain Core SDK interface should be idiomatic of the programming language for which it is written and exhibit best practices for that language.

R14. Obsolescence

Users should have a relatively cheap way to migrate their application to another platform or blockchain. Vendor lock-in should be minimized where possible. The user should be able to migrate data to new formats and migrate certificates to other blockchains or stores.

R15. Scale

The system should support public-key-infrastructure functions for at least single-digit billions of client devices where operation latencies are defined by quality-of-service tiers with reasonable costs.

R16. Privacy

The system should avoid publicly disclosing the relationship between a blockchain certificate and the user.