Format for data & symmetric key exchange/storage

Question

Is there a standard format for storing/exchanging encrypted data along with the key needed to decrypt it (data is encrypted with a single use symmetric key and the symmetric key itself is encrypted with asymmetric key for the receiver)?

We are trying to build an interoperable protocol to exchange large messages between two parties that may not agree on much else besides using asymmetric keys. The best way seems to be using a symmetric single use key to encrypt the data and then encrypt the symmetric key with the asymmetric key and pass along the whole thing as a package (e.g. RSA wrapped AES). So is there any widely used standard for sharing the encrypted text along with its key, preferably along with some information about the symmetric algorithm used.

The only work that I found in that direction is OpenPGP which I feel is somewhat too email focused. I was wondering if there is anything else that has more metadata along with it to describe the alogs and the keys.

Update: my application uses JSON to store some additional meta outside of the envelope.

Answer 1

One of standards is WSSEncryption. A message can be encrypted with symmetric algorithm e.g. AES-128 or AES-256. The encryption key itself can be encrypted with RSA.

Many software products support it out of the box. For instance, if you prefer Java EE, you may want to use WildFly or WebSphere Application Server. If you prefer C#, use WCF.

The web service standards WSSEncryption, WS-Security and SOAP in general are widely used and provide very good interoperability. Every party can use any platform it prefers. E.g. one party can use WildFly, the other WCF, and client on one one platform can consume web service implemented on another platform and vice versa.

Answer 2

It appears that JWE (RFC 7516) defines exactly that - meta + symmetric key + ciphertext format.

Answer 3

I don't understand why you think OpenPGP is 'implementation specific' -- it is the opened specification of what started out long ago as a single product, and there are now numerous implementations that interoperate fine precisely because the spec is open. Howsoever, ...

The classic solution to this problem started out as part of Public Key Cryptography Standard #7 from then-RSA Labs, later republished as rfc2315 -- specifically the EnvelopedData type (structure) in section 10. PKCS7 was turned over to IETF which renamed it Cryptographic Message Syntax and progressively enhanced it (rfc2630, rfc3369, rfc28562, and rfc5652) while remaining mostly compatible, in much the same way Netscape SSL became IETF TLS. These are based on ASN.1, itself a somewhat complicated standard that some people have had difficulty implementing; just google "ASN.1 vulnerability". And they normally manage keys using X.509 certificates (or at least PKIX, which is the Internet 'version' of X.509), which have also proven difficult for some people, although it is possible to use PKCS7/CMS without certs if you work at it.

Although CMS can be used by itself, it is also used as the basis for S/MIME -- a format for encrypted and/or signed email. MIME (Multipurpose Internet Mail Extensions) was created originally to handle non-textual material in email (like pictures, sounds, and video) but has evolved to handle almost any type or format of data, and S/MIME consists essentially of using CMS messages as the content for MIME emails. Because of the popularity of email, you might more easily find or get access to software doing S/MIME than raw CMS, even though in terms of security functionality they are identical.