Skip to content
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

Signed objects #160

Open
johnny-morrice opened this issue Jul 4, 2017 · 6 comments
Open

Signed objects #160

johnny-morrice opened this issue Jul 4, 2017 · 6 comments

Comments

@johnny-morrice
Copy link

johnny-morrice commented Jul 4, 2017

Signed objects for IPFS

In my experience with getting public key signage to work over IPFS, there are two categories of signed object.

Small signed objects

An IPFS app will likely store its data model in IPFS. It will also use IPFS to share data with other app instances. This will likely be stuff that user's don't really care about, such as, objects on a wire.

For example, my project maintains its own keystore to sign IPFS paths before sending the data over pubsub to other peers. A peer can sign the link to say "Yes, this is a good link" and if you trust any of those peers (e.g. you have their public key), you'll download the data from the link.

What would be really nice here would be if we could send such objects by pubsub without doing all the manual encoding as per MakeLinkMessage(Link) above.

I call these "Small" signed objects, not because I expected them to be tiny, just because I expect them to occupy less of the user's mindspace than the "Big" signed objects described next.

Big signed objects

A big signed object, is say, a program file from another user and you really want to make sure it is definitely from that person. Today, when someone wants to do this, they have the developer of the program sign her binary using PGP. Then they can download the certificate and verify it via PGP.

I'm aware that kinda the whole point of IPFS is that it's a permanent store, and that paths are generated from crypto signatures, but I really think supporting additional signing schemes would be a great feature for this use case. IPFS based apps would have much less friction operating with current systems that use PGP for instance.

Here's an example: the user downloads an Ubuntu package from IPFS, and IPFS looks up additional signatures stored alongside the package, and dumps out the PGP sig. The user can then verify that the file is from the Ubuntu developers, using the keys that are contained in their keyring by default. Edit: or I suppose the point of an integration would be that IPFS could do that logic itself.

There is also a useability issue if an app needs to use an existing key signing mechanism. Currently that means the user needs IPFS keys, and the other type of key. If IPFS can only support its own custom crypto keys, then that means the user must use IPFS keys and so have yet another private keyring to keep tabs on. Much better if they had the option to load in their existing keyring.

@whyrusleeping
Copy link
Member

havent read yet, just linking another related doc: https://github.com/ipfs/specs/tree/master/keychain

@Stebalien
Copy link
Member

The idea of general-purpose signature schemes is also related to something called IPRS (IP Record Scheme) (although IPRS also has the notion of order/precedence).

Personally, I'd like something like the following interface:

// I'm assuming we have access to a DAGService for resolving CIDs to IPLD Nodes.
type Validator interface {
    // Takes in a policy and an object to be validated under the policy.
    Validate(policy *cid.Cid, object *cid.Cid) -> bool, error
}

Where the policy can be something like:

{
    "policy-type": "/pgp/2.0",
    "keyring": <a set of trusted keys>,
}

Or, in the distant future, ...

{
    "policy-type": "/procedure/1.0",
    "procedure": <arbitrary code that can validate blocks>,
}

@johnny-morrice
Copy link
Author

johnny-morrice commented Jul 17, 2017

I'm really interested in finding better approaches for my work, so thanks for pointing me to IPRS.

(Source code for anyone interested https://github.com/ipfs/go-iprs)

It certainly looks like IPRS fulfils the "big" signed object criteria. It could definitely be used for verifying package signatures when distributing programs.

However, I get the feeling that IPRS is not yet in production. I cannot see options for it in ipfs, and when I search the go-ipfs tree for "iprs", I get nothing. It also doesn't build using "go get github.com/ipfs/go-iprs" because there are no go files in that directory.

I feel that for the package manager use-case IPRS will be somewhere that needs love.

@Kubuxu
Copy link
Member

Kubuxu commented Jul 17, 2017

https://github.com/ipfs/go-iprs is outdated stub of that package. IPRS as of right now has no solid spec unfortunately.

@Stebalien
Copy link
Member

(yes, sorry, it's just an idea at this point in time).

IMO, your "small signed objects" is just be a subset of your "big signed objects" (the policy is just "someone I know signed this").

@johnny-morrice
Copy link
Author

johnny-morrice commented Jul 17, 2017

Indeed it is the same thing, but in a different use case. What I am doing now is sending bytes containing the data+signature over pubsub. (Rather than say, adding that to IPFS and sending the hash).

I think if we were to have an official signed object, one could read the bytes of the object and send that over the wire just the same.

Edit: aware what I am doing now may be The Wrong Thing.

Edit 2: the optimal solution for this use case would be a small size for the signed object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants