> -----Original Message----- > From: Anders Rundgren [mailto:[email protected]] > Sent: Monday, August 10, 2015 1:53 PM > To: Jim Schaad; [email protected] > Subject: Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input- > options 00 > > On 2015-08-10 21:27, Jim Schaad wrote: > > 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. > > Sure. No disagreement on that. > > > 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. > > It seems that you require a solution to work with broken software as well?
How is the software broken. It meets the JSON standard and is sitting between me and the target system doing some type of snooping to verify that only data that should be is being transmitted. It may write things back out and not preserve the order which is completely legal JSON. > > My reference implementations in Java, JavaScript, and Python deal with > numbers in the same way as with all property data which is keeping the textual > information "as is". That is, a parsed property like > > "volume":1.50 > > would during serialization come out as > > "volume":1.50 Ah yes - we are going to make numbers into strings not numbers. I am not sure that this works for anybody sitting in the middle that does not know they are supposed to be doing this. Again - you have a special case solution not a general solution that will work with any JSON parser that I happen to write. I may have good reasons to use a hash table to keep the map in (makes it easier to do comparisons against known bad patterns for example). Any system that assumes that a JSON structure is going to be serialized out in the same order all of the time is not broken, but will cause you to exhibit failures. I am just not interested in this I guess. Jim > > This server may not always be up-and-running but you should after a few > minutes of playing be able to verify my claims: https://mobilepki.org/jcs > > > The problem as I see it is rather that the financial sector doesn't have a suitable > signature standard for JSON data. > > Anders > > > > > 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%2fxm > >>>> ln > >>>> 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%2fm > >>>>> ob > >>>>> 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%2fw > >>>>> ww > >>>>> .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
