"Inconsistency" actually cuts the other way. "Inconsistency" is when you do the same thing two ways. The current specs are inconsistent between JWE and JWS in terms of how the integrity-protected data are computed (JWS Signing Input vs. AAD). The proposal is to make the specs *consistent* in this regard, and to do different two things (protected+payload vs. payload) different ways.
As I said at the IETF meeting, there are a few compelling reasons, namely: We maximize the set of apps that can use JOSE by not mixing JOSE-specific stuff into the crypto. --Richard On Thu, Aug 29, 2013 at 11:22 AM, Mike Jones <[email protected]>wrote: > The primary problem with the proposal is that it makes signature > computations within the JSON serialization inconsistent by introducing an > unneeded special case. Let’s keep things simpler by always computing the > signatures the same way. There’s no compelling reason to have the special > case at all.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, August 29, 2013 8:16 AM > *To:* Justin Richer > *Cc:* Anders Rundgren; Jim Schaad; Mike Jones; [email protected] > *Subject:* Re: [jose] #59: Allow direct signing and align with AAD**** > > ** ** > > Not quite. The compact serialization is a subset of the JSON > serialization. For both the compact case and the equivalent JSON case, the > proposed algorithm doesn't change anything. Likewise for the JSON case > with any protected header (even if there are some unprotected headers). ** > ** > > ** ** > > The only change is when there is no protected header, which can only > happen in the JSON case.**** > > ** ** > > So the change only occurs for a subset of JSON cases. But that sort of > makes sense -- the JSON format is more general, so the signing algorithm > should be more general as well.**** > > ** ** > > --Richard**** > > ** ** > > On Thu, Aug 29, 2013 at 10:50 AM, Justin Richer <[email protected]> wrote: > **** > > Unless I'm missing something, this seems to be creating a special case for > the JSON serialization, making the signature calculation different from the > compact ones. I thought we had already decided not to do that? Seems we > really should keep things parallel, which will itself remove complexity. > > -- Justin**** > > ** ** > > On 08/28/2013 04:24 PM, Richard Barnes wrote:**** > > The proposal here is actually to *remove* complexity, especially for an > implementation that does both JWS and JWE. **** > > ** ** > > In the current scheme, I have to do different things to prepare the JWS > Signing Input and the JWE Authenticated Data, even though they're both > (header + data) inputs to integrity protection.**** > > ** ** > > function createJWSSigningInput(serializedProtectedHeader, payload) {** > ** > > return b64enc(serializedProtectedHeader) +'.'+ b64enc(payload); **** > > }**** > > ** ** > > function createJWEAuthenticatedData(serializedProtectedHeader, aad) {* > *** > > if (aad.length > 0) **** > > return serializedProtectedHeader + "." + aad; **** > > else return serializedProtectedHeader;**** > > }**** > > ** ** > > The proposal collapses these two into one function, which happens to have > an "if" statement.**** > > ** ** > > function createSigningInput(serializedProtectedHeader, payload) {**** > > if (serializedProtectedHeader.length > 0) **** > > return b64enc(serializedProtectedHeader) +'.'+ b64enc(payload)*** > * > > else return payload; **** > > }**** > > ** ** > > So we're actually saving lines of code here (9 lines to 5 -- a 44% > reduction! :) ) and reducing the probability of interop problems by doing > similar things the same way.**** > > ** ** > > ** ** > > ** ** > > On Wed, Aug 28, 2013 at 4:10 PM, Anders Rundgren < > [email protected]> wrote:**** > > On 2013-08-28 21:46, Richard Barnes wrote: > > Nope, sorry. This issue calls for a change to JWS/JWE, not something > else.**** > > Maybe your use-case also calls for another solution? > > Cramming a lot of functionality into JWS may render as useless as you claim > that XML DSig is. > > I FWIW didn't see that a message-in-signature-scheme would be a suitable > replacement for my current XML-based signature-in-message system. > > I still see great value in JWS and in fact already use it with Google apps. > > Cheers > Anders**** > > > > > > > > On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren < > [email protected] <mailto:[email protected]>> > wrote: > > > > On 2013-08-28 21:30, Richard Barnes wrote: > > > This is not that. Both of those issues had to do with the > representation of the signature in the message. > > > Issue #59 is about what gets signed, and what it proposes is much > more limited than the other two. > > > > Richard, > > > > No chance that Enveloped JSON Signatures meet your requirements? > > > > > http://webpki.org/papers/keygen2/doc/org/webpki/json/package-summary.html#package_description > > > > Here you have an authentic example with three signatures: > > > > { > > "MyLittleSignature": > > { > > "Version": "http://example.com/signature";, > > "Now": "2013-08-28T21:27:22+02:00", > > "HRT": > > { > > "RTl": "67", > > "YT": > > { > > "HTL": "656756#", > > "INTEGER": -689, > > "Fantastic": false > > }, > > "er": "33" > > }, > > "ARR": [], > > "BARR": > > [{ > > "HTL": "656756#", > > "INTEGER": -689, > > "Fantastic": true > > }, > > { > > "HTL": "656756#", > > "INTEGER": -689, > > "Fantastic": false > > }], > > "SignedObjects": > > [{ > > "ID": "this", > > "VALUE": 35, > > "EnvelopedSignature": > > { > > "SignatureInfo": > > { > > "Algorithm": " > http://www.w3.org/2001/04/xmldsig-more#hmac-sha256";, > > "Reference": > > { > > "Name": "ID", > > "Value": "this" > > }, > > "KeyInfo": > > { > > "KeyID": "symmetric-key" > > } > > }, > > "SignatureValue": > "B4N8pJI+Jwbw7nnb5UDtcR3WCpLloibVKNYJe+viCf4" > > } > > }, > > { > > "ID": "that", > > "VALUE": -90, > > "EnvelopedSignature": > > { > > "SignatureInfo": > > { > > "Algorithm": " > http://www.w3.org/2001/04/xmldsig-more#hmac-sha256";, > > "Reference": > > { > > "Name": "ID", > > "Value": "that" > > }, > > "KeyInfo": > > { > > "KeyID": "symmetric-key" > > } > > }, > > "SignatureValue": > "NvQzP+9hYtb5rfR2oZLbwq8dmi291gzc6Tc49FCOnCI" > > } > > }], > > "ID": "cDl5MXhuHdh1CvMht9fc", > > "STRINGS": ["One","Two","Three"], > > "EscapeMe": "A\\\n\"", > > "Intra": 78, > > "EnvelopedSignature": > > { > > "SignatureInfo": > > { > > "Algorithm": " > http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256";, > > "Reference": > > { > > "Name": "ID", > > "Value": "cDl5MXhuHdh1CvMht9fc" > > }, > > "KeyInfo": > > { > > "SignatureCertificate": > > { > > "Issuer": "CN=Demo Sub CA,DC=webpki,DC=org", > > "SerialNumber": 1377713637130,**** > > > "Subject": "CN=example.com < > http://example.com>,O=Example Organization,C=US"**** > > > }, > > "X509CertificatePath": > > [ > > > "MIIClzCCAX+gAwIBAgIGAUDGIccKMA0GCSqGSIb3DQEBCwUAMEMxEzARBgoJkiaJk/IsZAEZFgNvcmcxFjAUBgoJkiaJk/IsZAEZFgZ3ZWJwa2kxFDASBgNVBAMTC0RlbW8gU3ViIENBMB4XDTEyMDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowQjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGUgT3JnYW5pemF0aW9uMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABECkenu7FrOpy7J2FGeO1vrtseQqJT2GsaExxK5UVKe1zhFXjF+V8OFjv/FdM9fqdqwkP/YUnx5epvvHh/+/cQWjXTBbMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgP4MB0GA1UdDgQWBBR4YF2UOnLWDhOPLLuXYZum7xLMajAfBgNVHSMEGDAWgBRZXCF2vVvvaakHecbUVh7jS1yIVTANBgkqhkiG9w0BAQsFAAOCAQEAjBuZK2TcDhib12DSW8rW3kyjfQ3iYtjNSVd7vJ5jyI+0OYQ/NlhN4vVJx7Z02vnrBxv1Nh9swgT5Jpw0724KawGC4P+/bUEvKVz89tPMl9DaV98yQ2YN4cBfhcW3FpAoI4dzBbCzfEplsh9Ek7VxuIgwPozl0AdqOmTjZ3hh54ApSq/PMwENDyCEzD6bvrCrqCjgWSYIQUIvQ7LfO2HAlEE9DcoV4mSl/8uiQ05hRdGmNYUHZVUua0HHX1h/nAS+IcS6/EDd89kEGrL3M92a5wqnIQvDLO2NBCXhHSxoPVyBzv0lIgaO0ixD+q5P2OszRBYG3uk9W/uNIHdoyQn19w", > > > > > "MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEVMBMGA1UEAxMMRGVtbyBSb290IENBMB4XDTA1MDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowQzETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEUMBIGA1UEAxMLRGVtbyBTdWIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQI1w6lq0AsHbWMes8i/UGBeVQnlbzL2N8VyLjkbT3HXNHPUTjWWQElhoRzFA2xPaH++V/ecgr2Dkievrm+B5yIsdAL4oWWmgZ9KVMSfOrl5jy843p6AA55CHlP4j8v1uU1SpexIMUegDcNPlBwSRc0PPX+uqQ1STRg0kUgi4Bap7U5IRxTvp06adFXU4Bjr85ML7VZ3j+164t6mLnwF5RChJMlO7aVuz6TwxnWqeZytjFOei742dgbX9SHPVvytLtbFp4V/VFoEhaOXLZiOudPvpVwVdlfgE0AtiGHEWrfA74BU5XhME6UXzjcl3y3Ic304YGymo2jvmOwBki5wb3AgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRZXCF2vVvvaakHecbUVh7jS1yIVTAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAMlPdBaZ/+AMDfFYI9SLQenx0/vludp0oN9BSDe+mTfYNp5nS131cZRCKMAR3g/zzgkULu022xTJVsXfM1dsMYwEpGZp+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJRSUDGnoY65g50dgv > > > l1+ASbZX/r0/fNANLzXt/cnf0VXPrWdqvhuUSO561TsbTYg4qzcyDRV5vpjoUAxjFna06TJkeZR/OYMMcTtPRJON3/bMvzp7MFoL20PRPxu8nnqxwLWNzoQCkExS2yWHq1YDNNL4C/PIuyC/2IUbbPuwNp8ir3MVDBq4QwuXbw6xFvbPsxOmZyH10xvpsnmokg", > > > > > "MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwHhcNMDIwNzEwMTAwMDAwWhcNMzAwNzEwMDk1OTU5WjBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMR4ROlJJyBUzQ92XDSzFuxiMjwFqsrKXuIksIXMypjg2QZF4PzyQ0pu32/LVKuoaqbT+bkRKFdpUvMKhzGQ3rMAthTUkhXpFJN5Bk2LTcGXoE0B9wPKn4C3cxbUMEtT94m8PKIjRoKm77Rvdd4vrG1GiCw98WriMtNbX/psYzr/RikIcpEUpm4PPXzPPFuBzYIeDFG50aPEJu6arup5b1w7SQe6lq/f/XhKYWENH1LcQOFsMoQ8oUS/WsYQ8aeT6/FxjMumjv4f9LanUHb73bBPA0xiqtEfNIuK1ZogXgqT0157tqbmg2+GCSz+dGZv3VbSyQPdqh5s8YEGEK873vAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRaQnES9aDCSV/XOklJczxnqxI4/DAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAHyxu0Z74ZYbWdy/fUtI9uIid/7F5AjbDdTzJcZgbSvyF3ZYVF62pRjSyxtIcCKbbr/oRPf5voYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FTM1aCaJhu1RqioUK > > > X4omlilZqTkTq6lBmDOdN+5RyBoA28EV+stt3+NV1JzOxIFqEqJfMW1q4Bzg5RM/S4xy/jCj/hMSn2Etm5YoNVwju2L86JZ8433SoemQWjl7qMHEJ1tTMEG9hR5DiE9j6STtbza+WbJHGqSdY/z1IsYbNgoZgYtJbRtZ4aObZb4FxflMTvObXiOInYgeKdK+Dw" > > ] > > } > > }, > > "SignatureValue": > "MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neRqWjLv99t/WceEkRBFZkRxaVz2/GBLzaOw" > > }, > > "Additional": "Not signed since it comes after the > EnvelopedSignature" > > } > > } > > > > Cheers > > Anders > > > > > >**** > > > > On Wed, Aug 28, 2013 at 3:13 PM, jose issue tracker < > [email protected] <mailto:trac%[email protected]> > <mailto:[email protected] <mailto: > trac%[email protected]>>> wrote: > > > > > > #59: Allow direct signing and align with AAD > > > > > >**** > > > > Comment (by [email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]>>):**** > > > > > > > This largely seems to be an attempt to reopen issues #23 > (Make crypto > > > independent of binary encoding (base64)) and #26 (Allow for > signature > > > payload to not be base64 encoded), both of which were already > closed as > > > "wontfix". In particular, both of the already-closed issues > proposed > > > using an unencoded payload value as the signature input, > rather than the > > > encoded value, which is the same as what is is being > requested here. > > > > > > I therefore believe that this should be closed as a duplicate > of #26. > > > > > > -- > > > > -------------------------+------------------------------------------------- > > > Reporter: [email protected] | Owner: > draft-ietf-jose-json-web-**** > > > > Type: defect | [email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]>>**** > > > > Priority: major | Status: new > > > Component: json-web- | Milestone: > > > signature | Version: > > > Severity: - | Resolution: > > > Keywords: | > > > > -------------------------+------------------------------------------------- > > > > > > Ticket URL: < > http://tools.ietf.org/wg/jose/trac/ticket/59#comment:2> > > > jose <http://tools.ietf.org/jose/> > > > > > > _______________________________________________ > > > jose mailing list**** > > > > [email protected] <mailto:[email protected]> <mailto:[email protected]<mailto: > [email protected]>>**** > > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > > > > > > > > _______________________________________________ > > > jose mailing list**** > > > > [email protected] <mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > >**** > > ** ** > > ** ** > > _______________________________________________**** > > jose mailing list**** > > [email protected]**** > > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
