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 [email protected] > https://www.ietf.org/mailman/listinfo/jose > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
