There are many things about JWS which I dislike. However, the fact that it will allow for stupid intermediates to grab and potentially change things in ways which JSON permits is one of the things that is goodness.
I am afraid that I still believe that you do not have a workable solution to the problem at this time. There are far too many ways that order may not be respected and of course you don't deal with numbers. jim > -----Original Message----- > From: Anders Rundgren [mailto:[email protected]] > Sent: Monday, August 10, 2015 1:11 AM > To: Jim Schaad; 'Mike Jones'; [email protected] > Subject: Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input- > options 00 > > On 2015-08-10 08:54, Jim Schaad wrote: > > Anders, > > > > If you truly have a "Predictable Serialization" that is general > > purpose rather than only for a subset, please submit an ID with that > information. > > It would be highly valuable. The JSON group is re-opening and it > > could provide some good input for that. > > My take on "Predictable Serialization" is extremely simple both from a > definition- and implementation-point of view ; it only means that the order and > contents of properties is respected during parsing and serialization. This doesn't > violate RFC 7159 but isn't supported by it either. > > An I-D would mainly be a rationale. > > > > I do not find that humans do predictable serializations when creating > > JSON in any way. They tend to either copy some example or put in > > fields as they tend to remember them. They don't, for example, sort > > them in an alphabetic order by key name. > > Right. What I meant is that when humans are authoring JSON data they tend to > put properties in a for the context logical order. > > Anders > http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html > > > > > Jim > > > > > >> -----Original Message----- > >> From: jose [mailto:[email protected]] On Behalf Of Anders > >> Rundgren > >> Sent: Sunday, August 09, 2015 10:11 PM > >> To: Mike Jones; [email protected] > >> Subject: Re: [jose] Payment Perspective on > > draft-jones-jose-jws-signing-input- > >> options 00 > >> > >> On 2015-08-10 06:33, Mike Jones wrote: > >>> You can represent unencoded header and payload values by using > >>> "b64":false > >> > and "header" rather than "protected" with the JWS JSON Serialization. > >> > >> Got that but "header" is not signed, right? > >> > >> Anyway, the bigger picture is that "Predictable Serialization" is the > > de-facto > >> standard for HUMAN-authored JSON data including the JOSE RFCs and I-Ds. > >> > >> By adding a mere 10-100 lines (required by _some_ JSON tools), you > >> can > > finally > >> close the readability gap between HUMAN- and MACHINE-written JSON data. > >> > >> If you do that you also get an entirely different set of > >> possibilities for > > human- > >> readable, byte-efficient, and simple "in-object" JSON signatures like JCS. > >> > >> For detached signatures (which IMO is another story) I think your I-D > >> is > > quite > >> useful! > >> > >> Anders > >> > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: jose [mailto:[email protected]] On Behalf Of Anders > >>> Rundgren > >>> Sent: Saturday, August 08, 2015 9:48 AM > >>> To: [email protected] > >>> Subject: [jose] Payment Perspective on > >>> draft-jones-jose-jws-signing-input-options 00 > >>> > >>> 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": > >> > "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtc > >> GxlLmNvbS9pc19yb290Ijp0cnVlfQ", > >>> "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": > >> "https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fxmln > >> s.web > >> > pki.org%2fwebpay%2fv1&data=01%7c01%7cmichael.jones%40microsoft.com% > >> > 7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011d > >> > b47%7c1&sdata=zRirh4Ml%2bLrdObxfyIKPEiT%2fWTV8EkvxaWPwafW0ong%3d > >> ", > >>> "@qualifier": "ProviderGenericAuthRes", > >>> "paymentRequest": > >>> { > >>> "payee": "Demo Merchant", > >>> "amount": "94617.00", > >>> "currency": "USD", > >>> "referenceId": "#1000002", > >>> "dateTime": "2015-08-08T14:17:22Z", > >>> "softwareId": > >> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=0 > >> 1%7c > >> > 01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b > >> > 64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXe > >> U8QTmBGIvMxL%2fjTb1GKdtHSo%3d - 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": > >>> [ > >>> > >> > "MIIDQzCCAiugAwIBAgIGAU6V7cELMA0GCSqGSIb3DQEBCwUAMDAxCzAJBgNV > >> BAYTAkRFM > >>> > >> > SEwHwYDVQQDExhNZXJjaGFudCBOZXR3b3JrIFN1YiBDQTUwHhcNMTQwMTAxM > >> DAwMDAwWhc > >>> > >> > NMjAwNzEwMDk1OTU5WjA2MQswCQYDVQQGEwJERTEPMA0GA1UEBRMGOD > >> k2MzI1MRYwFAYDV > >>> > >> > QQDEw1EZW1vIE1lcmNoYW50MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg > >> KCAQEAgwj > >>> GibfiCx8SOPyM- > >> xWnxPg7T2Aqyww3SpD0n8nPEs0DPWHZEVNsATd3dYLCTk7iEyGlKnR_Z > >>> CeC018fC6cg9Yqc- > >> vcvg7SG21JNm05q1XG0h6mVnyNNlRBVEq36CPoRiiyHdFIa9UfA141 > >>> > >> > ZJAvONgejEVWSe4ZSNxxo81hvebQQc2lHs7n9LvSB4tc7qfgNRvjffgXTpwtcumeXg > >> N_42 > >>> kIJSANVwwKj6HhXZVnaHHQ4M- > >> cL9_BWjWQIr8VmQvi4Ijq9fIa6GMjYoOlznBbnUjsmALA > >>> 0CRXYc- > >> > 3mxQbeKUDal1Z8fsstXsSBOSm1T0Im4oGbuPFKAuF5LqlxSmcnHQIDAQABo10wW > >>> zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID- > >> DAdBgNVHQ4EFgQUehiUWQGM9QOs31qpSTK > >>> > >> > CIasVC8gwHwYDVR0jBBgwFoAU8hS_eJVH7LntNHSRqkO_Y3rJxCIwDQYJKoZIhvc > >> NAQELB > >>> > >> > QADggEBAAYB5NqFPxHwIyQWkQY3Ip4nIFfCHzOEJ4CyBZG0nrZPi4696Nf66iR1W > >> 0xJxPo > >>> 0PTFHD1Q1sRlhbonEh1rrQpNctzZtS8jEo6VeskH7MiGq3wUV9pfnQys0_2j0- > >> GTnVlXwC > >>> > >> > kMKnBRIWue4MdbZJplahOS3QbD4w1HcXGlaluWoCGCS_8eIVPHmTTSCmGOU3J > >> X-PIZoV7V > >>> _q-wevUwAJfoeWF > >> 21E > >>> > >>> > >> > Kgic3yQWvIgoDQEeSRjg7f3LDTrr2J9uVqXMTTkTvsTKCYNZoUTeM66Rxa1nTSryu > >> 866Nu > >>> j9XmKorNmDAmrxN4tX64tzNIMnaoTXv6qifQal0hEVRlE7ONUNfY", > >>> > >> > "MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w0BAQ0FADAxMQswCQYDVQQGEwJV > >> UzEiMCAGA > >>> > >> > 1UEAxMZTWVyY2hhbnQgTmV0d29yayBSb290IENBMTAeFw0xMjA3MTAxMDAw > >> MDBaFw0yNTA > >>> > >> > 3MTAwOTU5NTlaMDAxCzAJBgNVBAYTAkRFMSEwHwYDVQQDExhNZXJjaGFudC > >> BOZXR3b3JrI > >>> > >> > FN1YiBDQTUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCbOtyy4Q > >> Z5re1twR7 > >>> 9TDAQ0we0cGLlfUW920F3lVnov7aEec7zRtUBVKsSs- > >> MVfiuDFmhTSfULT52o_mv5Re76n > >>> > >> > 0AdbKsV61sQDInXFDPLPUWxayuWJaHu3TzisjQOKupor25V8zHzqAVU5fuGsvYD0 > >> uPUwjn > >>> cRVQU9GmUU49iKu0D5Twf4GSkDRiUoouwJ2CQnGLVie4ImMHAK- > >> vlHc5cvg1zd_G3HEECg > >>> g-EYYXbwUppb- > >> 7KiH6Z3ftWJZsiE22nGtrYbXNH4ESp_NNYbMyLP1Nu1XFvUc9Y2jCzXcG > >>> > >> > oe4FDcrTC6QhdRARVY3oNMDRTLpQcc0nUWfvTnZNk8IONAgMBAAGjYzBhMA8 > >> GA1UdEwEB_ > >>> > >> > wQFMAMBAf8wDgYDVR0PAQH_BAQDAgEGMB0GA1UdDgQWBBTyFL94lUfsue0 > >> 0dJGqQ79jesn > >>> EIjAfBgNVHSMEGDAWgBQbQarjDLZwVQi- > >> a9eysaPNhSKG7jANBgkqhkiG9w0BAQ0FAAOCA > >>> > >> > gEAeyGWd5HUJEtJfwOgHF7OTby7sx6OuYw4EApUCfsDBLHZwFY5vPZvhOZYTYxB > >> FmHyVxZ > >>> > >> > BRvikWuCeDn6TP8uDDWbwnLESVAAgGAxK1y4mMzP32SHESnnrehcrJrhwxA3xbp > >> KsTeolN > >>> ceOVB8XzKz9Ti3TmmDt9VA20aruGw- > >> Zv8XIF036oNpOY4SBz0Hvfu_CrLEZXrhKqKvmS9N > >>> 9m44Us8L6FZbRNa > >> Pfk > >>> > >> > VIfKRBGgtMziDUyyXrb0PisuRkdFenmkoqfO2d6QVho6SuNUlXd_pGNklKaQfEP- > >> A6vN4XK7JpYhwgmhvrxKUUC9nfx601olcIcUm3TpewUz5t- > >> > s2Kpv4EVCAet6vKqHDH4A4oI2hOPEWSzhjqumtJmPguNGVdeBbdgZrVEl3XbwsRO > >> qgYGGHLXURSRnySaIaUY-4Se8HgA-AHbn3MiK_pBz1Igj- > >> mokjZILt51t6I77Qf_fTi9OJYBrAPkZozxUGN2RaQ6zPqPlIgrKQQwS_jTQg- > >> z_QkctYP8V7w9__Z6Na8dCR9rBhoruBdKO1OPipT_qeqRVq3xzu- > >> > 80MFDRNouegE4UoS8_KTMwfisCKssrKydA7IIACMKa6V3BtGKD6ML3LhnhgfGQS > >> oCxVU4v5QZ6866TImLRSl-E8M8SdeIZ4MKRV-oKPouq6B0d-0mrHkCstTilfI" > >>> ], > >>> "value": "AYUvS4Nq7cuHz8zCoXh_- > >> vOWYKchnAAUfROaDbU1nGv9cM3H0uZz- > >> W6d8v51jlBGq0bt9yWDpyjmd9FFqHSqLEf1FNTGTObAEpQ2ar6Lgvwmer- > >> > HXhi3Y5Hng7MqMokOZeF_tsbfZTffXg96BvFVRzUr3qBeCYPNMH7q2pTV_4L57sj4 > >> QssJkRfG-KxT1nSkhSGCD1big2Vfr_93CC0cKuURSJup2AwK- > >> A3BJ3ax5QlW4YA2KBRiaSf6X1jlJhCFQZf- > >> oaj7bUIna7kWd_f0ab869Co4H4HoDvECoDKa-JHqNw- > >> NOeUAxT0brMHyKJ_Nvq8LUuiAzic3CPqIJaJSHA" > >>> } > >>> }, > >>> "cardType": "SuperCard", > >>> "cardReference": "************2109", > >>> "referenceId": "#164010", > >>> "dateTime": "2015-08-08T14:17:37Z", > >>> "softwareId": > >> "https://na01.safelinks.protection.outlook.com/?url=WebPKI.org&data=0 > >> 1%7c > >> > 01%7cmichael.jones%40microsoft.com%7ce83bbb0608b14320772308d2a0111b > >> > 64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nGtCZFiJGh02Zn7OXe > >> U8QTmBGIvMxL%2fjTb1GKdtHSo%3d - 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": > >>> [ > >>> > >> > "MIIBtjCCAVmgAwIBAgIGAU6V7ZqUMAwGCCqGSM49BAMCBQAwLzELMAkGA1 > >> UEBhMCRVUxI > >>> > >> > DAeBgNVBAMTF1BheW1lbnQgTmV0d29yayBTdWIgQ0EzMB4XDTE0MDEwMTA > >> wMDAwMFoXDTI > >>> > >> > wMDcxMDA5NTk1OVowMTELMAkGA1UEBhMCRlIxDTALBgNVBAUTBDQ1MDEx > >> EzARBgNVBAMTC > >>> > >> > m15YmFuay5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQsqMMQgB9jB > >> PfnNXhQo9Q > >>> SGp1P0OF8-2VZp-BEeRmk3kNRH1y2E0f0A- > >> y1DVC34oOF71EyPeAv74mxhjc3gElgo10wW > >>> zAJBgNVHRMEAjAAMA4GA1UdDwEB_wQEAwID- > >> DAdBgNVHQ4EFgQU3butViPf_sGq0YGegUK > >>> > >> > NflI4I7YwHwYDVR0jBBgwFoAUiJnScUmlW9Sj8LhXJ5MCsWtU6EQwDAYIKoZIzj0E > >> AwIFA > >>> > >> > ANJADBGAiEApr5pe3Oeqr2Ep7xfs6s011Z5w9SaoumonMnD6_UQrFYCIQCAE2vi1 > >> QoIzr8 > >>> gH800AnBrdOtG9Xw9jI-Vb1ixyow0tA", > >>> > >> > "MIIDcjCCAVqgAwIBAgIBAzANBgkqhkiG9w0BAQ0FADAwMQswCQYDVQQGEwJV > >> UzEhMB8GA > >>> > >> > 1UEAxMYUGF5bWVudCBOZXR3b3JrIFJvb3QgQ0ExMB4XDTEyMDcxMDEwMDAw > >> MFoXDTI1MDc > >>> > >> > xMDA5NTk1OVowLzELMAkGA1UEBhMCRVUxIDAeBgNVBAMTF1BheW1lbnQgT > >> mV0d29yayBTd > >>> > >> > WIgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEwR1b9NmpqCEX7wJb391 > >> eOhqzmBr > >>> > >> > aQyHpvZ2Y0WmkEHXQcKx3pWg_0jalhZpNmmmcfM_TzmqrID4ZDGoKimC4iaNj > >> MGEwDwYDV > >>> > >> > R0TAQH_BAUwAwEB_zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFIiZ0nFJ > >> pVvUo_C4Vye > >>> > >> > TArFrVOhEMB8GA1UdIwQYMBaAFJm5JC6Uimm49w3xJhmpWpxn3DozMA0GCS > >> qGSIb3DQEBD > >>> QUAA4ICAQAO5pRZZMkLt3EelSdX2V5bOz4iC- > >> XfSed9PJYuR2slXij3w2DFmxYHmbSVH4d > >>> ZshotkFHCHAhoLpZdtq6IeYdkEGuf94corvBh8hPxqetn-F- > >> qLVUpdFwEww1POd8T0n02Y > >>> ouRDSi4HWUY003C9hB6ouTdfHaswR6- > >> cBOpKzwOqfRUGdBG_pDdP_XURIIgxPt6wp3PGd3 > >>> 2gS6FLMO-GOfFIQJgQ2lZNPQ-UPaa0UGmNI- > >> GcDkco_kI1eOlPlWfZPZwe9bLWyE_g380l > >>> > >> > _ozm2waLM8p9tVNUqp37ktLUeIJbBS_u4vR8j3h9QVBrSVitddQbkGFyxLDB_dkuQ > >> jNDig > >>> > >> > ESmCBgbjeoa5DSxNGc_FkHDVkJyTkTjL5vvG9cee9kqlRjWM4KEXPVJcBcNyGPqis > >> myMWN > >>> > >> > gIm1TJC7Z7tm_epvzoJnfN35RUW7cUjPyRZtIsymnqs_uILyY_cmTWUmH1c75Utg > >> Tx1-Jf > >>> p6B3Qyji8pDR_Ba > >> 3eU > >>> > >> > lz1BJhyFuC8cHL275S8zQ2jCyjnaMXZvm_EnZGpOcm4DZrPD3cujBc1E09LyujylglLi > >> N_up0I_ImliqF0GIA1o-s3nk7F1QlTe- > 7HWsbTrPOocm3SHDmyJEOgz8ChftelxeQ5- > >> 2hhz5QURdmmUIPUrDBcK1I5Fopv2-SPmNipPkZ1o7Gz1Mbqzrg" > >>> ], > >>> "value": > >> > "bUZ2bjXVKQisr_RyYG1Ru0P263ft1LkmhLnBTg94AjYQ4YLXLdwImmcZUd6yzApC > >> SARFZ6xOoYw_IuvvkBG_ug" > >>> } > >>> } > >>> > >>> thanx, > >>> Anders R > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmob > >>> il > >>> > >> > epki.org%2fjcs&data=01%7c01%7cmichael.jones%40microsoft.com%7ce83bbb > >> 06 > >>> > >> > 08b14320772308d2a0111b64%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd > >> ata= > >>> 4BxnKZzwfjHI9agf8KmyH9r8uq99%2bcJuynTGLfe7F5U%3d > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> [email protected] > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww > >>> .i > >>> > >> > etf.org%2fmailman%2flistinfo%2fjose&data=01%7c01%7cmichael.jones%40mi > >> c > >>> > >> > rosoft.com%7ce83bbb0608b14320772308d2a0111b64%7c72f988bf86f141af91 > >> ab2d > >>> > >> > 7cd011db47%7c1&sdata=SZEW0IWLt8eUw0nPilbQE45376rM41ChicZcQmLOeAE > >> %3d > >>> > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
