Square Open-Sources Golang Crypto Package Based on JWE/JWS

Good point, but apexskier/cryptoPadding doesn't have any license info, so it really shouldn't be used at all (importing, copying, or vendoring).

Here are polished versions of my pkcs7 functions from the crypto challenges if anyone wants:

http://play.golang.org/p/xfAGpytsSI

Also, remember to not leak padding errors and always MAC your ciphertext. Wouldn't want you to spring a padding oracle.

Why?

Every time I see JOSE/JWE/JWS/JWT I want to cry. SPKI did this, better, more readably and more attractively, back in 1999. It was also more reliable: JSON itself imposes no ordering on object elements (i.e., '{"foo": 1, "bar": 2}' and '{"bar": 2, "foo": 1}' are equivalent, but they will hash to entirely different values, while '((foo 1) (bar 2))' and '((bar 2) (foo 1))' are not at all equivalent).

Moreover, SPKI was flat-out more readable. Compare:

    (sequence
     (cert (issuer (hash sha256 |mbKsNmlDk1d1WGcl1s25LDCYeCGjDgC7FFNSdBK8PIE|))
           (subject (bearer))
           (valid (not-after 2011-03-22_12:43:00))
           (tag (http://example.com/is_root true)))
     (signature (hash sha256 |0XVRFpmUgNOep+Mud3FrmQC5d52r3PPVVnJyYtMK800=|)
                (hash sha256 |mbKsNmlDk1d1WGcl1s25LDCYeCGjDgC7FFNSdBK8PIE=|)
                (ecdsa-sha256
                 (r |xOUGRpq1a3V6cnn/fVgfEgCuxDCy9HO1Nyhni6NBgr8=|)
                 (s |miT9LZh7VlBDscXn++n2+zcjtoQejDJ8v0G37RQGsaQ=|))))

to:

    {
      "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
      "protected": "eyJhbGciOiJFUzI1NiJ9",
      "header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
      "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
    }

By comparison, the SPKI version is a model of clarity: one can actually see the thing being attested-to; by contrast the JSON version base64-encodes its assertion '{"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}' (the SPKI version is the '(cert …)' expression). Likewise, where the JSON version base64-encodes '{"alg":"ES256"}' the SPKI version just writes 'ecdsa-sha256'.

As noted, in the JSON '{"alg":"ES256"}', '{"alg": "ES256"}', '{"alg":\n"ES256"}' and '{"alg":\r\n"ES256"}' all are different values, even though they mean the exact same thing. In contrast, SPKI uses canonical S-expressions, so that 'ecdsa-sha256' encodes to '12:ecdsa-sha256'. Likewise, there are a literally infinite number of ways to encode the JSON payload, whereas with SPKI's canonical S-expressions the certificate will always encode to a string '(4:cert(6:issuer(4:hash6:sha25632:…))(7:subject' and so forth, meaning that the given attestation will always yield the exact same value, with the exact same hash.

Moreover, the key identification semantics are much cleaner in SPKI. In the JSON version, the key id 'kid' is an opaque value; in one example in the standard it's a date and in another it's a UUID of unknown provenance. In SPKI, keys (principals) are identified by their hashes (the JSON stuff can't do this since there's no repeatable way to hash a JSON-encoded key). So the signing key is referred to as '(hash sha256 |mbKsNmlDk1d1WGcl1s25LDCYeCGjDgC7FFNSdBK8PIE|)' and there's never any ambiguity or concern—and certainly no collisions!

And of course SPKI supports a whole lot more than just bearer tokens, being a complete PKI (better thought-out than XPKI too).

I propose a corollary to Greenspun's Tenth Law: Any sufficiently complicated data-representation contains an ad hoc, dubiously-specified, hideous, inelegant equivalent to S-expressions.