Cryptographic Message Syntax

[richardschneider]

RFC 5652 (aka PKCS #7) can be used to encrypt data.

See also richardschneider/ipfs-encryption#1 (comment)

[richardschneider]

@jbenet Any comments?

[richardschneider]

@diasdavid Perhaps you can help?

[daviddias]

@richardschneider where does this multicodec get used?

[richardschneider]

@diasdavid It will be used by ipfs add --encrypt key-name path. It returns a CID v1 that indicates the content is encrypted and/or signed.

Then ipfs cat ... can detect that the content is CMS and auto-magically decrypt the contents if the key is present in the current keychain.

[richardschneider]

Any comments on this. Will need this soon!

[daviddias]

@richardschneider I do not expect this to work with the current model of bitswap. Either you are proposing that:

• a) the serialized data is of format CMS
• b) the unixfs dag will use this multicodec as metadata. However, this is currently not supported in unixfsV1.

//cc @Stebalien

[richardschneider]

I may be missing something but I thought bitswap is all about blocks. It doesn't need to know about the contents of the block (encrypted or not).

Why can't ipfs.cat just do the work.

Maybe I need to readup on unixfsV1, can u give me some URLs

[richardschneider]

@diasdavid Perhaps there is a better way

All I'm trying to do is to allow IPFS to determine that the serialised data is encrypted and not plaintext. Then, when needed, it can automatically decrypt the data if the key is present.

Eventually this mechanism can be used to verify the signatures in the serialised data, if it is also signed.

[Stebalien]

So, multicodecs used in CIDs are used to determine the structure of the data being referenced. So, this multicodec wouldn't instruct IPLD to decrypt the data, just to decode it into some structured object (probably with a field indicating the encryption algorithm, another with the data, maybe one for a signature, etc.). The actual encryption/decryption will have to be handled at a higher level (e.g., in IPFS or in some layer between IPFS and IPLD).

However, the primary motivation for multicodecs in CIDs was compatability with existing content addressed systems (eth, git, etc.). In this case, is there any reason not to simply encode this structured data in CBOR? We could still define a mapping (importer) between CMS and IPLD but I'm not sure what we'd get out of the ability to interpret CMS files as IPLD (without importing them).

[richardschneider]

@Stebalien Thanks for the detailed reply

CMS data is self describing, it has encryption algorithm, key name(s), etc.

So, it appears that I'm abusing CID. If I use CBOR, is there some way to indicate that the data block contains CMS data? Sorry, don't know anything about CBOR.

All I'm trying to do is to allow IPFS to determine that the serialised data is encrypted and not plaintext. Then, when needed, it can automatically decrypt the data if the key is present.

[Stebalien]

So, if you're familiar with JSON, IPLD is a way to interpret and write merkledags composed of structured JSON-like nodes that link to each other. CIDs just tell you how to interpret a binary blob as an IPLD node (as structured, merkle-linked data).

So, it appears that I'm abusing CID. If I use CBOR, is there some way to indicate that the data block contains CMS data? Sorry, don't know anything about CBOR.

So, the way I'd do this is to:

1. Deserialize the CMS file.
2. Reserialize it as CBOR.

At that point, it'll be a nice, structured IPLD object.

However, that won't tell you what the object is. What you seem to want is a nominative type system, which we don't currently have (but want eventually).

However, you can easily build one on-top-of IPLD by adding a special field, e.g., @type (arbitrary, choose what you want), to the object. You can make this field:

1. Contain a simple string describing the type (e.g., "cms").
2. Or, even better, you can add the relevant RFC to ipfs and use the CID.

[richardschneider]

Hey guys, I really think this is good idea. Many issues have been raised on how to encrypt data in IPFS.

This allows a reader to know that the content is protected by CMS. It's much like the protobuf, cbor and bson in that it describes the format of data.

[mikeal]

This is quite similar to how we’re looking to do AES encrypted blocks ipld/specs#349

The objections are rather out of date, we’re using multicodecs for a lot of things that fall outside the requirements stated above. If there is still interest in this multicodec I’d support its approval.