Java Reference
In-Depth Information
Signing and Encrypting Message Bodies
Sometimes you have RESTful clients or services that may have to send or receive HTTP
messages from unknown or untrusted intermediaries. A great example of an intermediary is
Twitter. You post tweets to Twitter through the Twitter REST API, and one or more people
can receive these tweets via Twitter. What if a tweet receiver wanted to verify that the tweet
originator is who he says he is? Or what if you wanted to post encrypted tweets through
Twitter that only trusted receivers could decode and read? This interaction is different from
HTTPS in that HTTPS is a trusted SSL socket connection between one client and one server.
For the Twitter example, we're sending a representation that is retransmitted via a totally dif-
ferent HTTP request involving different clients and servers. Digitally signing or encrypting
the representation gives you the protection you need in this retransmission scenario.
Digital Signatures
Java developers are intimately familiar with the
HashMap
class. The way maps work is that a
semi-unique hash code is generated for the key you are storing in the map. The key's hash
code is used as an array index to quickly look up a value in the map. Under the covers, a di-
gital signature is simply an encrypted hash code of the piece of data you are transmitting.
While a shared secret can be used to generate and verify a digital signature, the best approach
is to use an asymmetric key pair: in other words, a private and public key. The signer creates
the digital signature of the message using its private key. It then publishes its public key to
the world. The receiver of the message uses the public key to verify the signature. If you use
the right hash and encryption algorithms, it is virtually impossible to derive the private key
of the sender or fake the signatures. I'm going to go over two methods you can use to lever-
age digital signatures in your RESTful web services.
DKIM/DOSETA
for email. Work is also being done to apply this header to protocols other than email (e.g.,
er that contains a digital signature of one or more headers of the message and the content.
What's nice about DKIM is that its header is self-contained and not part of the transmitted
representation. So if the receiver of an HTTP message doesn't care about digital signatures,
it can just ignore the header.
The format of a DKIM header is a semicolon-delimited list of name/value pairs. Here's an
example:
