On Fri, Mar 20, 2015 at 12:26 PM, Derek Atkins <derek(_at_)ihtfp(_dot_)com>
wrote:
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> writes:
We have been having a similar discussion in ACME which is for issue of
certificates for use in TLS, email, etc.
The body of the message is going to be JSON. But the message needs to be
signed. After a number of proposals we seem to have settled on a scheme in
which the start of the message is a JSON header carrying the signature which
is
followed by a JSON message carrying the transaction request or response.
Okay, I'll bite.. Why don't you use JWS? That would seem to be the
appropriate way to sign JSON, no?
The idea is to use JWS for the signature. The only part that is not in
the JWS spec would be the 'JWS Serialization' signature packaging.
There are two versions of this in the current spec. All we are
proposing is to add a third.
JWS Compact Serialization is essentially
BASE64URL(UTF8(JWS Protected Header)) || '.' ||
BASE64URL(JWS Payload) || '.' ||
BASE64URL(JWS Signature)
This is designed for use in OpenID. For our purposes, it is much easier to use:
JWS Signature
.
JWS Payload
The advantages of this change are:
1) It is more efficient in space (no need to base 64 encode)
2) It is easy to interpret examples and debug implementations if you
can see the plaintext without a tool
3) In our application, there isn't actually a need for the protected
header. But we could add that in as well just to keep things straight.
I can't see much point in going to JSON so that we have the benefits
of plaintext and then base64 encoding everything just to be compliant
with a spec written for a different purpose.
If adopted, I am sure that the JWS group will pick the scheme up and
add it to their spec at their next iteration. They have two
serialization formats today, adding a third is hardly an imposition.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp