Not entirely sure what you're asking; if your apps natively support a specific format, use that. Is there a specific app you'd like to ask about?
If you just want a simple format for apps you're writing, the OpenSSH format is nice and simple (and widely used / supported). Also X.509 certificates are a little more complicated, but also widely supported, though that might be a bit beyond the scope of what you're trying to do (X.509 is a full spec for PKI [Public Key Infrastructure] and PMI [Privilege Management Infrastructure]).
OpenPGP also has free implementations (gnupg), and has good library support / a nice key format (when using ascii armoring).
On a semi-offtopic note, generating the private key server-side and then giving it to the client is almost always a bad idea that defeats the purpose of public/private key crypto. Instead you should pre-seed the clients with the servers public key, generate a private key on the client, use the servers public key to verify the connection (if you're already using TLS you've done this part) and then send the server the client's public key. Also, if you're already using TLS I'm not sure why you'd need another layer, then again, I don't know what use case you had in mind.
To get an example of each key on a Unix/Linux system:
ssh-keygen -t rsa -b 2048 -f filename
gpg --keyserver pgp.mit.edu --recv-key 0xEC2C9934 && gpg --armor --export 0xEC2C9934 (will download and display my public key)
openssl genrsa -sha512 -out keyfile.key 2048 will spit out a private key.
You can then generate a certificate signing request using
openssl req -new -key keyfile.key -out keyfile.csr and finally a certificate:
openssl x509 -req -days 1 -in keyfile.csr -signkey keyfile.key -out keyfile.crt
After reading the comments, it seems you're looking for more of a full solution. If I understand what you want, I think the ideal solution would be to use X.509 certificates. You could either create your own CA (Certificate Authority) or purchase a certificate from a trusted third party online (I like RapidSSL). You can then have your apps verify communications from the server, and use ECDH (Eliptic Curve Diffie–Hellman) to negotiate a shared key and facilitate secure communications (You said you wanted small footprint, so I figure ECDH will be faster than normal DH). AES256 for encryption and SHA2 for message digest verification should give you a secure, well supported, and reasonably low overhead connection. Basically just use TLS and make sure you choose good options for the encryption type, key exchange mechanism, and message digest function.