Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

Anders Rundgren Mon, 10 Aug 2015 13:53:23 -0700

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?

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

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

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

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

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

Re: [jose] Payment Perspective on draft-jones-jose-jws-signing-input-options 00

Reply via email to