-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for publicKeyMultibase. #94
Conversation
@@ -141,16 +141,25 @@ const generateDidCorePropertiesTests = ( | |||
it('5.2.1 Verification Material - A verification method MUST NOT ' + | |||
'contain multiple verification material properties for the same ' + | |||
'material. For example, expressing key material in a verification method ' + | |||
'using both publicKeyJwk and publicKeyBase58 at the same time is ' + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
related to w3c/did-core#731
@msporny see also multiformats/multicodec#210 We can't support publicKeyMultibase for a key type until we can represent the private key component... currently Ed25519 is the only key type to have a private key representation... I expect over developers will be bothered enough by this to delay upgrading, and would welcome PRs to fix it. |
This is factually incorrect. One does not preclude the other. You can support That said. PRs on the security vocab for |
so you do this:
? Of course this can be done... by point is that you cannot produce |
I feel like you could be trying to make a variety of different points, but it's not clear which one (or what you want us to do about it)... what point are you trying to make? What action would you like those reading this thread to take based on your point? I suggest:
Would the above address your concerns? NOTE: I continue to believe that all three items above are a terrible idea, and you're going to inflict a lot of pain on the industry by doing this, but also admit that if you don't do it, someone else will come along and do it (because JSON-LD has decentralized semantics, so no one can stop anyone from doing anything, no matter how dangerous the idea is -- FREEDOM! * screamed in william wallace *). |
multibase table? |
@msporny you nailed all it, thats exactly what I intend to do. But I was asking what you are planning, will you use |
No, multicodec table: https://github.com/multiformats/multicodec/blob/master/table.csv#L128 |
Why does multicodec come into play here? My understanding is that the values of |
We won't use We don't export private keys to other systems as a general security principle. We may do it in the future if our customers request the feature, but we will try very hard to talk them out of it and to use key rotation in DID Documents instead. We need to move the industry beyond this really broken concept of exporting private key material. |
The multibase-encoded byte string has a header for not only the base encoding, but the key type as well. So the format can be: <MULTIBASE_HEADER><KEY_TYPE_HEADER><KEY_BYTES> I say "can" because cryptosuites can choose to do something else... like not put the key type header on there. |
@msporny you do use
|
@msporny I know that the format can be like that with multicodec, but the discussion around <MULTIBASE_HEADER><KEY_BYTES> Not saying that I find multicodec good or bad, but to my knowledge it simply hasn't been part of the discussion so far. See also comments here: w3c/did-core#707 (comment) |
Note that I said:
You'll note that we don't specify Our libraries also take other protections, like ensuring that if you JSON stringify that object, that you don't accidentally print the private key material to the outgoing string. Again, we're trying to balance being pragmatic (sometimes you need to generate a private key and convert the private key and thus need access to the private key material on the same system). Exporting it from that system to some other system as |
If the value of
That might be useful, but could also lead to discussions about cryptographic agility, similar to |
We should not do this for the same reason that we shouldn't repeat JWKs mistakes. If you're going to express a key type, be specific about it. We don't want MulticodecKey2021 because it imports a gigantic attack surface (that is always getting larger). |
Ultimately, this is a decision for each cryptosuite to make. It's an added 1-2 byte protection to make sure the developer hasn't accidentally shoved the wrong key type into the field. |
Agreed.. Then why would someone ever want to include a value like |
See #94 (comment). |
Okay.. I feel like it might be a bit better to standardize that for the property itself rather than delegating it to cryptosuites, but can live with this as well :) Thanks for explanations. |
fyi, we will be / are doing Just because root accounts are bad to use for everything does not mean they should not exist... for us, we see migration from JWK as only happening incrementally, and we think that adding 1-1 feature coverage is part of enabling that upgrade... we think not doing that is dooming |
I'm not really against this either, I just wonder if in this case it wouldn't be better to define both |
@peacekeeper I guess this is mostly building off work that started here: https://github.com/w3c-ccg/did-method-key https://w3c-ccg.github.io/lds-ed25519-2020/ Possible we named |
The real name could have been ... and that discussion hasn't settled yet. In the end, we deferred to the cryptosuites on the final call here and the property makes no assertion to the inner format other than it being encoded as multibase. |
If it makes any difference in your argument to them because of the way the JS engine garbage collects and shallow copies strings, it's much harder to manage how long a private key remains in memory when compared with a Buffer which can be overwritten with all 0s once you've finished use of the key within the scope of the function where you create the variable. |
If only there was a standard for encrypted a private key before exporting it as a string.... oh wait... https://datatracker.ietf.org/doc/html/rfc2440#section-3.6 Our PGP suite supports this: https://github.com/OR13/lds-pgp2021/blob/main/src/PgpKeyPair2021.ts#L23 It introduces another set of challenges... now you need to remember passwords somewhere... This feels a bit like arguing that gasoline is dangerous, but also used to drive cars, so the solution is to not use cars that run on gas... or banning knives because they can be used to kill people in addition to cutting up food so you don't choke.... how exactly are you going to cold storage your crypto without exporting a private key or its generator to paper? There are many legitimate reasons for being able to export a private key, and yes, encrypting before exporting is a best practice... perhaps we should register a multcodec for "encrypted" private key?... under what scheme? with what cipher? |
It's telling that you link to a security specification from 1998 to make a point :) -- that's exactly the sort of thinking we need to stamp out. I can point further back to ASN.1 expression of private keys... that we /can/ do something doesn't mean we should. Remember, 1998 was a time where there really weren't the sorts of practices we have around private key management (like FIPS certified HSMs) that we have today.
Passphrase is optional? That's a nice footgun you have there... I can't wait until our engineers pick up your library and blow our leg off with it. :)
Yeah... the whole "let's export private keys" is riddled with all sorts of problems.
The solution is exactly not to use cars that run on gas... that's why the world is moving to electric, because gasoline-powered cars are not sustainable. In the same vein, exporting private keys are not sustainable... we can do much, much better.
There are well known security industry standards related to doing this that don't require either of the solutions you've put forward. Raw private keys don't need to leave devices... systems that allow private keys to leave devices are fundamentally less secure than ones that don't. We have created a mechanism, in DIDs, that allow us to rotate ourselves out of this problem instead of carrying it forward to the future. It doesn't work in every case, that's true, but we really need to start treating this as a dangerous exception instead of standard practice.
There are very few legitimate reasons... those reasons just happen to be that HSMs are expensive and out of reach for most people... I'd rather we fix that problem than keep focusing on creating footguns.
Sounds like a job for standards... :) |
All multibase PRs (w3c/did-core#707 via PRs w3c-ccg/security-vocab#103, w3c/did-spec-registries#299, and w3c/did-core#731) have been merged. Merging this to reflect the updates to the spec. |
just because its old doesn't mean we need to reinvent it every 2 years... crypto standards are not js front end frameworks :)
Sorry, what standard approaches to exporting private keys are there other than exporting them as plaintext or cipher text?
But what if this assumption is wrong? and what do you mean by "leave" you generated on a device from a seed, but let the seed move?
100% agree |
This PR is in support of addressing w3c/did-core#707 via PRs w3c-ccg/security-vocab#103, w3c/did-spec-registries#299, and w3c/did-core#731 based on the plan put forth in w3c/did-core#707 (comment).
It should be merged last, after all the other PRs have been merged.