Java Reference
In-Depth Information
b
Base 64-encoded signature.
What's nice about DKIM is that you can include individual headers within your digital signa-
ture of the message. Usually
Content-Type
is included.
To verify a signature, you need a public key. DKIM uses DNS text records to discover a pub-
lic key. To find a public key, the verifier concatenates the selector (
s
parameter) with the do-
main (
d
parameter):
<
selector
>.
_domainKey
.<
domain
>
It then takes that string and does a DNS request to retrieve a
TXT
record under that entry. In
our previous example,
burke._domainKey.example.com
would be used as the lookup
string.
This is a very interesting way to publish public keys. For one, it becomes very easy for veri-
fiers to find public keys, as there's no real central store that is needed. Second, DNS is an in-
frastructure IT knows how to deploy. Third, signature verifiers can choose which domains
they allow requests from. If you do not want to be dependent on DNS, most DKIM frame-
works allow you to define your own mechanisms for discovering public keys.
Right now, support for DKIM in the Java world is quite limited. The RESTEasy framework
does have an API, though, if you're interested in using it.
JOSE JWS
JOSE JSON Web Signature is a self-contained signature format that contains both the mes-
pletely text-based and very compact. It consists of three Base 64-encoded strings delimited
by a
.
character. The three encoded strings in the JOSE JWS format are a JSON header de-
scribing the message, the actual message that is being transmitted, and finally the digital sig-
nature of the message. The media type for JOSE JWS is
application/jose+json
. Here's
what a full HTTP response containing JWS might look like:
HTTP
HTTP
/
1.1 200
OOK
Content-Type
:
application/jose+json
eyJhbGciOiJSUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
