[jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00
Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 08 August 2015 16:47 UTC
Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D01A90F0 for <jose@ietfa.amsl.com>; Sat, 8 Aug 2015 09:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLsHxx6dfDij for <jose@ietfa.amsl.com>; Sat, 8 Aug 2015 09:47:49 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456341A8A58 for <jose@ietf.org>; Sat, 8 Aug 2015 09:47:49 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so93818298wib.0 for <jose@ietf.org>; Sat, 08 Aug 2015 09:47:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=V5l80pUNP3DfLbudIx1Y/N+3myX+uetc8f9lDRGXtMU=; b=kOMqiaiV31yinM33CY8zJe4PR/6jn4MPl8w8hXeXoTgXQL1GJKGMY3p/iAdec0BtGO sqIo+hP62Mhsurfe37zCIoutE/uyT5ZwyrfmGhNGqsN12Ej3/n5QP2pU9LahKMlVQKJk u1fIpQ4EwZX+Nmw3TGdBIWNV6VdDY3c/jmAEvG5S2Go7mJuadqaDLjd1u7yxWblFuecM yQF/xL0xvRBU6Q2YFAkrWP98/RQw6ZPJSfqK+oRdyTHXlaGJ+5fdp+uBaPSRci+UM0fQ +jupqQU2RvpKUgpWZXPTMpMoWOLD1tSp7ba6UtpUxkBevRwaX/oh6xtPdKadTire1Wy1 lKKA==
X-Received: by 10.194.47.209 with SMTP id f17mr27217185wjn.39.1439052467976; Sat, 08 Aug 2015 09:47:47 -0700 (PDT)
Received: from [192.168.1.79] (27.195.130.77.rev.sfr.net. [77.130.195.27]) by smtp.googlemail.com with ESMTPSA id s1sm4546891wix.13.2015.08.08.09.47.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Aug 2015 09:47:47 -0700 (PDT)
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: "jose@ietf.org" <jose@ietf.org>
Message-ID: <55C632B0.9060304@gmail.com>
Date: Sat, 08 Aug 2015 18:47:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/YOf3DmqHH9Hh4hZX1mPogoerY-o>
Subject: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2015 16:47:52 -0000
Hi JOSE WG,
The JOSE standards grew out of OpenID and similar. They obviously do a great job in that space!
So the question I have tried to answer is: How do the JOSE standards fit in a more traditional XML or EDI context?
SIZE:
If we start with size (which probably is the least important factor here), JOSE signature schemes seem to have one thing in common: they need to Base64URL-encode protected header arguments which for X.509 certificates means two layers of Base64. It doesn't take an Einstein to figure out that signatures schemes that use header protection for explicit X.509 data won't be particularly space-efficient.
READABILITY:
This is a more complicated issue than one might think because JSON unlike its "predecessors" does not depend on (or support) position-based data which for example makes the modified sample in JWS A.7
{
"signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q"
"protected":"eyJhbGciOiJFUzI1NiJ9",
"payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
"header": {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
}
fully valid but slightly less pleasing to read. Applied to JSON objects with dozens of properties this (IMO) becomes a debug and document hurdle also for systems that do not use signatures.
Now going back to readability which was one of the motives behind draft-jones-jose-jws-signing-input-options 00...
As far as I can tell, draft-jones-jose-jws-signing-input-options 00 doesn't really deal with signed JSON, it is rather a scheme for signing arbitrary UTF-8 data. If you use this scheme for in-line signing of JSON data, readability would suffer due to 1) typical JSON serializers' inability maintaining "insertion order" 2) the code getting garbled by escape characters.
That protected headers are Base64URL-encoded is also a readability (and debug) impediment.
If you would like to use a JSON schema for input validation things become rather "hacky" since the signature and the data isn't in the same format.
In some applications (like the ones I work with...), there's also a disadvantage with embedding signatures since they change the structure of an object completely. That signed PDFs is not about putting PDF data inside of a CMS blob is not a coincidence!
All those issues put together plus the fact that "predictable serialization" is absolutely trivial to implement and has legitimate uses outside of signatures makes me less convinced that the JOSE WG at this stage has a viable solution for payments and such.
However, that DOES NOT disqualify draft-jones-jose-jws-signing-input-options 00 as a possible extension to existing JOSE standards. The detached version of the concept seems like a particularly useful thing!
So, I'm still counting on a new scheme for payments. Although the following JCS sample may look verbose, it is actually quite a bit more byte-efficient than current JOSE signature schemes. Readability? Not even "pretty-printing" breaks signatures. Well, strings must of course not be folded...
{
"@context": "http://xmlns.webpki.org/webpay/v1",
"@qualifier": "ProviderGenericAuthRes",
"paymentRequest":
{
"payee": "Demo Merchant",
"amount": "94617.00",
"currency": "USD",
"referenceId": "#1000002",
"dateTime": "2015-08-08T14:17:22Z",
"softwareId": "WebPKI.org - Merchant",
"softwareVersion": "1.00",
"signature":
{
"algorithm": "RS256",
"signerCertificate":
{
"issuer": "CN=Merchant Network Sub CA5,C=DE",
"serialNumber": "1437034463499",
"subject": "CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE"
},
"certificatePath":
[
"MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxMDAwMDAwWhcNMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGODk2MzI1MRYwFAYDVQQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgwjGibfiCx8SOPyM-xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_ZCeC018fC6cg9Yqc-vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXgN_42kIJSANVwwKj6HhXZVnaHHQ4M-cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA0CRXYc-3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTKCIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvcNAQELBQADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W0xJxPo0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0-GTnVlXwCkMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3JX-PIZoV7V_q-wevUwAJfoeWF21EKgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu866Nuj9XmKorNmDAmrxN4tX64tzNIMnaoTXv6qifQal0hEVRlE7ONUNfY",
"MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJVUzEiMCAGA1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAwMDBaFw0yNTA3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4QZ5re1twR79TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs-MVfiuDFmhTSfULT52o_mv5Re76n0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0uPUwjncRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK-vlHc5cvg1zd_G3HEECgg-EYYXbwUppb-7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcGoe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8GA1UdEwEB_wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue00dJGqQ79jesnEIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi-a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCAgEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxBFmHyVxZBRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbpKsTeolNceOVB8XzKz9Ti3TmmDt9VA20aruGw-Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N9m44Us8L6FZbRNaPfkVIfKRBGgtMziDUyyXrb0PisuRkdFenmkoqfO2d6QVho6SuNUlXd_pGNklKaQfEP-A6vN4XK7JpYhwgmhvrxKUUC9nfx601olcIcUm3TpewUz5t-s2Kpv4EVCAet6vKqHDH4A4oI2hOPEWSzhjqumtJmPguNGVdeBbdgZrVEl3XbwsROqgYGGHLXURSRnySaIaUY-4Se8HgA-AHbn3MiK_pBz1Igj-mokjZILt51t6I77Qf_fTi9OJYBrAPkZozxUGN2RaQ6zPqPlIgrKQQwS_jTQg-z_QkctYP8V7w9__Z6Na8dCR9rBhoruBdKO1OPipT_qeqRVq3xzu-80MFDRNouegE4UoS8_KTMwfisCKssrKydA7IIACMKa6V3BtGKD6ML3LhnhgfGQSoCxVU4v5QZ6866TImLRSl-E8M8SdeIZ4MKRV-oKPouq6B0d-0mrHkCstTilfI"
],
"value": "AYUvS4Nq7cuHz8zCoXh_-vOWYKchnAAUfROaDbU1nGv9cM3H0uZz-W6d8v51jlBGq0bt9yWDpyjmd9FFqHSqLEf1FNTGTObAEpQ2ar6Lgvwmer-HXhi3Y5Hng7MqMokOZeF_tsbfZTffXg96BvFVRzUr3qBeCYPNMH7q2pTV_4L57sj4QssJkRfG-KxT1nSkhSGCD1big2Vfr_93CC0cKuURSJup2AwK-A3BJ3ax5QlW4YA2KBRiaSf6X1jlJhCFQZf-oaj7bUIna7kWd_f0ab869Co4H4HoDvECoDKa-JHqNw-NOeUAxT0brMHyKJ_Nvq8LUuiAzic3CPqIJaJSHA"
}
},
"cardType": "SuperCard",
"cardReference": "************2109",
"referenceId": "#164010",
"dateTime": "2015-08-08T14:17:37Z",
"softwareId": "WebPKI.org - Bank",
"softwareVersion": "1.00",
"signature":
{
"algorithm": "ES256",
"signerCertificate":
{
"issuer": "CN=Payment Network Sub CA3,C=EU",
"serialNumber": "1437034453652",
"subject": "CN=mybank.com,2.5.4.5=#130434353031,C=FR"
},
"certificatePath":
[
"MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDExEzARBgNVBAMTCm15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jBPfnNXhQo9QSGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A-y1DVC34oOF71EyPeAv74mxhjc3gElgo10wWzAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID-DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUKNflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0EAwIFAANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1QoIzr8gH800AnBrdOtG9Xw9jI-Vb1ixyow0tA",
"MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJVUzEhMB8GA1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391eOhqzmBraQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNjMGEwDwYDVR0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJpVvUo_C4VyeTArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCSqGSIb3DQEBDQUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC-XfSed9PJYuR2slXij3w2DFmxYHmbSVH4dZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F-qLVUpdFwEww1POd8T0n02YouRDSi4HWUY003C9hB6ouTdfHaswR6-cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd32gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI-GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l_ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQjNDigESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqismyMWNgIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75UtgTx1-Jfp6B3Qyji8pDR_Ba3eUlz1BJhyFuC8cHL275S8zQ2jCyjnaMXZvm_EnZGpOcm4DZrPD3cujBc1E09LyujylglLiN_up0I_ImliqF0GIA1o-s3nk7F1QlTe-7HWsbTrPOocm3SHDmyJEOgz8ChftelxeQ5-2hhz5QURdmmUIPUrDBcK1I5Fopv2-SPmNipPkZ1o7Gz1Mbqzrg"
],
"value": "bUZ2bjXVKQisr_RyYG1Ru0P263ft1LkmhLnBTg94AjYQ4YLXLdwImmcZUd6yzApCSARFZ6xOoYw_IuvvkBG_ug"
}
}
thanx,
Anders R
https://mobilepki.org/jcs
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- [jose] Payment Perspective on draft-jones-jose-jw… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Mike Jones
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Jim Schaad
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Mike Jones
- Re: [jose] Payment Perspective on draft-jones-jos… Jim Schaad
- Re: [jose] Payment Perspective on draft-jones-jos… Jim Schaad
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Mike Jones
- Re: [jose] Payment Perspective on draft-jones-jos… Nat Sakimura
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Sergey Beryozkin
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Sergey Beryozkin
- Re: [jose] Payment Perspective on draft-jones-jos… Sergey Beryozkin
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren
- Re: [jose] Payment Perspective on draft-jones-jos… Anders Rundgren