privateKeyMultibase

[OR13]

Where will it be defined?

See also w3c-ccg/security-vocab#62

[dmitrizagidulin]

It's now defined in https://github.com/w3c/vc-di-eddsa/blob/main/contexts/lds-ed25519-2020-v1.json#L9C10-L9C28
@OR13 does that address your concerns?

[OR13]

No, because it's still not defined... "privateKeyMultibase"....

Editing for clarity... In order to represent private keys, you need to describe how they are encoded... If they are curve based, how are the points represented, if they are RSA or lattices, how are the private components represented, etc... Just pointing to a prefix table in multicodec is not enough to ensure the private components can be processed consistently... Many implementations will need to convert from multikey to COSE or JWK in order to use off the shelf libraries etc... Without defining the shape of the private key, it's not possible to do this... And imo, a new key representation that doesn't support or document how to represent private keys, is not helpful, or an improvement.

To resolve this, you need to describe how the private components of multikeys are represented... Just like you do for public keys ( although I don't know that public keys are defined sufficiently either )

[dmitrizagidulin]

@OR13 Ah, ok, so this is less about including the the term in a context, and more that you'd like to see better specification of it in the spec itself?

[OR13]

It's both.

I don't think "not defining things in a context" is a security mechanism.

And I would never recommend a public key serialization that did not have well defined representation for private keys.

Since raising this, multicodec has added prefixes for representing private keys.

But where are they defined? How are the EC and RSA private keys structured, etc...

You can close this if you don't think it's worth specifying, we are not planning to implement.

[dmitrizagidulin]

@OR13 PR w3c/vc-data-integrity#148 adds secretKeyMultibase to the DI vocab

[OR13]

When w3c/vc-data-integrity#148 is merged this can be closed.... however, I still urge caution when considering secretKeyMultibase... particularly since each multikey might present private keys differently, especially for different key types like RSA, vs compressed point ECDSA, vs EdDSA...

[msporny]

however, I still urge caution when considering secretKeyMultibase... particularly since each multikey might present private keys differently, especially for different key types like RSA, vs compressed point ECDSA, vs EdDSA...

Why do you urge caution? What's the security issue you're alluding to?

[OR13]

@msporny the security issue is that each private key representation can be different, and there is little reason to believe that 2 serialized Ed25519 private keys will be represented the same way, because there is no standard that defines how that would be done.

This is in contrast to JWK, JWA... https://www.rfc-editor.org/rfc/rfc7518.html#section-6.2.1.2

For example, where is it defined that privateKeyMultibase for Ed25519 has a public key in it, whereas privateKeyMultibase for P-256 does not?

[dmitrizagidulin]

@msporny the security issue is that each private key representation can be different, and there is little reason to believe that 2 serialized Ed25519 private keys will be represented the same way, because there is no standard that defines how that would be done.

@OR13 - I opened issue #56 to address this.

[msporny]

This issue is now a dupe of the more accurate issue #35. Closing.