Re: [jose] Enveloped JSON signatures

[David Waite <[e-mail]>]

On Jul 23, 2013, at 12:49 AM, Anders Rundgren <[e-mail]> wrote:

> On 2013-07-18 17:21, Phillip Hallam-Baker wrote:
>> I agree that enveloped signatures are useful. But trying to do that in XML or JSON is quite painful without resort to Base64 encoding or the like.
> 
> I have used enveloped XML signatures in XML for about 10 years and the only problem I have experienced is the many options which makes interoperability difficult.

Me too, although I’ve experienced a few security and interoperability issues with a static set of options chosen ;-)

The big issue that I see is that JSON parsers are diverse enough across implementations that you wont be able to round trip into a canonical form without defining some additional limitations on supportable parser functionality. The big examples are numerical representations (not all languages even support infinite floating point precisions) and the behavior when multiple identical elements are found. 

You also have implementations which represent as object types internally, meaning that an ISO 8601 date may be a Date object in some implementations and a non-declared key on an object might be represented internally by a value ‘false’. This brings back some of the DTD and schema-related canonicalization issues in XML if you don’t specifically disallow it.

You also have two root types in JSON; object and array. An enveloped signature on an array would not be transparent like your object example below, because the signature would be a member of the array.

Without the ability to round-trip data, you could choose a preprocessing route, where signature verification happens before you load into the JSON engine. You then have a choice between making your wire form look like JSON (and risk having implementations parse and regenerate causing a non-canonical transform), or make it look like something else so that you require new tooling to support it.

And if you decide to make it look like something else, you probably have JWS :-)

-DW

> Although I haven't yet decided on switching to JSON (for market adoption reasons only, technically there's no need at all) I have come up with a scheme that inherits stuff from JWS that could work:
> 
> {
>    "ElementToBeIncludedInTheEnvelopedSignature": {
>        "arbitrary_but_required_identifier_and_unique_data": "5fr70ydte",
>        "PayloadData": "The_meat_of_the_message",
>        "envelopedsignature": {
>            "arbitrary_but_required_identifier_and_unique_data": "5fr70ydte",
>            "protected": "integrity_protected_header_contents",
>            "header": "non_integrity_protected_header_contents",
>            "signature": "signature_contents"
>        }
>    }
> }
> 
> Naturally you need a canonicalization scheme but I believe it could be quite simple and still even support multiple signatures.


> 
> Anders
> 
>> 
>> The problem is where to define the start and end of the signed text. Add some whitespace, do a trivial reformat and the position is lost. 
>> 
>> This is where ASN.1 has an advantage over JSON. Which would be fine if it didn't also come with so many disadvantages. ASN.1 is the CPL of binary encodings and XML is the CPL of text encodings.
>> 
>> Fortunately we now have JSON which is the C of text encodings. It may not be pretty, it may not support every need but it does the job for 95% of all needs. Unfortunately there remains a 5% in which there is no substitute for a binary encoding.
>> 
>> Which is the reason Casten and Paul have been looking at CBOR and while I have been working on JSON-B, C and D.
>> 
>> http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00
>> 
>> 
>> What I am trying to do here is not compete with JSON for the purposes that JSON is good at. In fact a compliant JSON-B reader will read JSON without modification, a JSON-B reader will read JSON or JSON-B and a JSON-C reader will read any of them.
>> 
>> The idea of JSON-BCD is not to compete with JSON, it is to minimally extend the JSON syntax so as to address the missing 5% in which binary is essential so that we can use JSON to drive a steak through the heart of ASN.1 (preferably fillet).
>> 
>> 
>> I would like to use JSON-B as a wrapper for Jose data.
>> 
>> 
>> 
>> On Thu, Jul 18, 2013 at 4:45 AM, Anders Rundgren <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>    Hi,
>>    I'm hooked on enveloped signatures i XML.  I'm considering dropping XML for JSON.
>>    I guess enveloped signatures won't be a part of JWS?
>> 
>>    Why enveloped signatures you may wonder?
>>    Well, in most schemes the root/top element is the message/type indicator
>>    and it is of course nice if a signature can cover the entire message.
>> 
>>    thanx
>>    Anders
>> 
>>    <ProvisioningInitializationResponse
>>          Attestation="NxcMqBJGQi...hcKoS2wPQm7rvRc="
>>          ClientTime="2013-07-09T18:13:52+02:00"
>>          ID="C-13fc435e15fe1f9c7534beb0a08"
>>          ServerSessionID="S-13fc435e0099bb7345b0bf57a85"
>>          ServerTime="2013-07-09T18:13:52+02:00"
>>          xmlns="http://xmlns.webpki.org/keygen2/beta/20121228#"
>>          xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>          xmlns:ds11="http://www.w3.org/2009/xmldsig11#">
>>        <ClientEphemeralKey>
>>            <ds11:ECKeyValue>
>>                <ds11:NamedCurve URI="urn:oid:1.2.840.10045.3.1.7"/>
>>                <ds11:PublicKey>BEdD3W6GslfY/AVEkRTD8MqT2R24iYnb+qvs2zP8PWXfecMNioEYR5P1VWPnKLPbRm1JMWPNrgBcTrBPebJ0eKc=</ds11:PublicKey>
>>            </ds11:ECKeyValue>
>>        </ClientEphemeralKey>
>>        <DeviceCertificatePath>
>>            <ds:X509Data>
>>                <ds:X509Certificate>MIIC2DCCAcCgAwIBAg...xtVD5cD1Gcn7KNdcJfLt</ds:X509Certificate>
>>            </ds:X509Data>
>>        </DeviceCertificatePath>
>>        <ds:Signature>
>>            <ds:SignedInfo>
>>                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
>>                <ds:Reference URI="#C-13fc435e15fe1f9c7534beb0a08">
>>                    <ds:Transforms>
>>                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>>                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>                    </ds:Transforms>
>>                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
>>                    <ds:DigestValue>bQymGISGazFazPrSFcl45YrUBYPzF1sZ1O+29zpfx+w=</ds:DigestValue>
>>                </ds:Reference>
>>            </ds:SignedInfo>
>>            <ds:SignatureValue>ZN1QM20uWIfHd4rloiqtQqRRf6jAgifcFlzNxqlnk84=</ds:SignatureValue>
>>            <ds:KeyInfo>
>>                <ds:KeyName>derived-session-key</ds:KeyName>
>>            </ds:KeyInfo>
>>        </ds:Signature>
>>    </ProvisioningInitializationResponse>
>> 
>>    _______________________________________________
>>    jose mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> 
>> 
>> -- 
>> Website: http://hallambaker.com/
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose