Differences among the keys


#1

I am reading DPKI paper. And I come across some keys:like master private key, subkey.
I can not figure out what are they.
I previously think that the master private key is private key which can be used to sign the credentials.
Then the subkey is public key? Or something else? Why they have the different name here? To differentiate from the concepts in PKI?


#2

I’m not sure exactly which paper you have read, but it sounds like you might be learning about an HD Keys scheme. HD = “Hierarchical Deterministic”. An HD Keys scheme is one where you create a master private key, and then you derive many public+private keypairs from that master one. Each derived keypair is a “subkey”.

In HD Keys schemes, you can end up with trees of keys, and you can revoke entire branches. Also, you can prove that a key is derived from your master key, without revealing the master key, and without that relationship being detectable prior to your proof.


#3

Thanks @danielh. for your reply.
I am reading the DPKI. A White Paper from Rebooting the Web of Trust.

The knowledge of HD should be the background knowledge.


#4

Hi @danielh,
is Sovrin using HD Keys scheme? From my understanding it is.

Many thanks ahead and best regards

Zuko


#5

Sovrin is not actively using Hierarchical Deterministic Keys schemes at present. However, some HD Keys schemes are relevant to future plans for key management.


#6

Thank you for your awnser but are the derived dids created with the any correlated key or somethink?
Because I’dont see how they are linked to the subject or identity owner?


#7

I’m not certain which “derived DIDs” you are referencing, and I’m also not sure what link to the subject or identity owner you think they have. The link between a DID and an identity owner is one of key possession; if an identity owner possesses the keys for a DID, then she or he can prove control of that DID. No derivation process is necessary.

Your use of the word “subject” makes me think you are talking about Verifiable Credentials. VCs have a “subject”, which is the person described by a claim. In a birth certificate VC, there are 3 subjects–the child, the mother, and the father. Each might have a DID, but these DIDs don’t have any particular relationship to one another or to a given key.

In the data model for VCs as described by the W3C community group, the assumption is that the user of a credential shows that they are the subject of the VC by proving control of the DID mentioned in the credential. This is only weakly assumed, however, because the spec explicitly says it isn’t describing a protocol for using VCs–only a data model for creating them. How VCs get used is likely to evolve into a spec of its own, sometime in the future.

Sovrin and Indy don’t pay any attention to the DIDs in a VC. Instead, they prove an association between the VC and its holder through the use of a link secret, which is described here: Proving claim ownership without sharing DID?

Now, having said all of that, there is a sort of derivation process between keys and DIDs in Indy/Sovrin. It is that the initial keypair is generated, and then the DID is derived from half (I think the top 16 bytes) of the public key. In other words, the hex (or base58) for the DID and the hex (or base58) for its public key will start the same. This derivation provides a guarantee of chain of custody for the DID from its inception.