The input into all JOSE integrity protection calculations (MAC, signature and AAD) is the octets of the ASCII representation of base64url content or multiple base64url content pieces concatenated together with a dot. JOSE is consistent in that respect. It was a decision made by the WG to avoid the complexity and interop issues that come with c18n. That decision has been reaffirmed numerous times by the WG.
I agree with the majority of folks on this thread who have said that this issue should be closed. On Thu, Sep 5, 2013 at 11:16 AM, Mike Jones <[email protected]> wrote: > Yes, the full equations are as follows. The previous ones intentionally > only covered the case where there is a JWE aad value specified, since I > thought was the case we were discussing. > > > > ToBeSigned = base64url(Protected JWS Header) + “.” + > base64url(Payload) > > ToBeAad = base64url(Protected JWE Header) + (aad ? (“.” + > base64url(aad)) : “”) > > > > The “?” conditional above is necessary so as to be compatible with > pre-draft-13 JWE values in the case where there is no “aad” field. > > > > There are two problems with the equation that you propose: > > [JSI/AAD] = (protectedHeader)? base64url(protectedHeader) + "." > + [payload/aad] : [payload/aad] > > > > 1. It always includes the “.” when there is a protected header, even where > there is no “aad” field specified. This breaks every current compact JWE > value and every JSON JWE value without an “aad” field. (To fix this, you > would have to reintroduce the “?” in the original equation.) > > > > 2. There is no compelling reason for the special case introduced by your > “?”. > > > > For these reasons, I believe that this issue should be closed as “wontfix”. > > > > -- Mike > > > > From: Richard Barnes [mailto:[email protected]] > Sent: Thursday, September 05, 2013 7:15 AM > To: Jim Schaad > Cc: Mike Jones; [email protected] > > > Subject: Re: [jose] #59: Allow direct signing and align with AAD > > > > Those equations would be helpful if they were accurate. Mike's analysis > misses the key "if" statement. Allow me to quote JWE more fully: > > > > JWS: > > """ > > The concatenation of the Encoded JWS Header, a period ('.') character, and > the Encoded JWS Payload > > """ > > > > JWE: > > """ > > [in Sec5.1 -- oops!] Let the Additional Authenticated Data encryption > parameter be the octets of the ASCII representation of the Encoded JWE > Header value. ... > > [in Sec5.2] Let the Additional Authenticated Data encryption parameter be > the octets of the ASCII representation of the Encoded JWE Header value. > However if a top-level "aad" member is present when using the JWE JSON > Serialization, instead let the Additional Authenticated Data encryption > parameter be the octets of the ASCII representation of the concatenation of > the Encoded JWE Header value, a period ('.') character, and the "aad" field > value. > > """ > > > > In equation / code form: > > > > JWSSigningInput = EncodedJWSHeader + "." + EncodedJWSPayload > > JWEAAD = (aad && aad.length > 0)? EncodedJWEHeader + "." + aad : > EncodedJWEHeader > > > > Thus, we have two forms of inconsistency in the current specifications: > > 1. The JWE routine is inconsistent with the JWS routine (because it requires > the conditional) > > 2. The JWE encryption and decryption routines use inconsistent definitions > of "Additional Authenticated Data" > > > > An illustration: Suppose you have the encoded header > eyJhbGciOiJIUzI1NiIsIm9oIjoiY29tZV9vbiJ9Cg, and the empty string for the > payload/aad > > JWSSigningInput = eyJhbGciOiJIUzI1NiIsIm9oIjoiY29tZV9vbiJ9Cg. > > JWEAAD = eyJhbGciOiJIUzI1NiIsIm9oIjoiY29tZV9vbiJ9Cg > > (No final '.' in the last case) > > > > The proposal in ISSUE-59 resolves these inconsistencies by changing all of > the above to something equivalent to the following: > > """ > > Let the [JSI/AAD] be the [payload/aad]. If the [Protected Header] is > non-empty, then set the [JSI/AAD] to the concatenation of (1) base64 > encoding of the [protectedHeader], (2) a period (".") character, and (3) the > base64url encoding of the [payload/aad]. > > """ > > > > In other words: > > [JSI/AAD] = (protectedHeader)? base64url(protectedHeader) + "." + > [payload/aad] : [payload/aad] > > > > Is there anyone here who finds that one "if" statement complex or ambiguous? > If not, I don't understand what we're arguing about. > > > > > > > > > > > > On Thu, Sep 5, 2013 at 1:03 AM, Jim Schaad <[email protected]> wrote: > > Being drugged is not helping me at this point. I would like to point out > that equations make this much simpler to compare and decide if it is wrong. > > > > ToBeSigned = base64url(Protected JWS Header) || “.” || base64url(Payload) > > > > ToBeAad = base64url(Protected JWE Header) || “.” || base64url(aad) > > > > > > From: [email protected] [mailto:[email protected]] On Behalf Of Mike > Jones > Sent: Wednesday, September 04, 2013 6:03 PM > To: Richard Barnes > Cc: [email protected] > > > Subject: Re: [jose] #59: Allow direct signing and align with AAD > > > > There was a point of fact in dispute at the end of today’s call – > specifically whether the JWS Signing Input and JWE Additional Authenticated > Data encryption parameter are currently computed in a consistent manner or > not in the case where an “aad” header parameter is present in the JWE. The > intent of this note is to clarify this point of fact. > > > > The JWS Signing Input is computed as: > > “The concatenation of the Encoded JWS Header, a period ('.') character, and > the Encoded JWS Payload.” (See > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-15#section-2) > > > > The JWE Additional Authenticated Data encryption parameter is computed as: > > “the concatenation of the Encoded JWE Header value, a period ('.') > character, and the "aad" field value.” (See > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-15#section-5.2 > step 14.) > > > > Note that the “aad” field value is the base64url encoded representation of > the actual AAD value supplied: > > An "aad" (Additional Authenticated Data) member can be included to supply a > base64url encoded value to be integrity protected but not encrypted. (See > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-15#section-7.2.) > > > > Thus, both computations concatenate the base64url encoding of the protected > header, a period character, and the base64url encoding of the value to be > integrity protected. They are (already) consistent with one another. > > > > -- Mike > > > > Endnote 1: The language on how to use the “aad” field in the JWE AAD > computation is taken directly from the proposal in the issue. (See the NEW > text in http://trac.tools.ietf.org/wg/jose/trac/ticket/29.) > > > > Endnote 2: In reading the JWE spec to clarify this point, I discovered that > the language about the “aad” field cited from JWE § 5.2 step 14 is currently > missing from JWE § 5.1 step 15. I have corrected this cut-and-paste mistake > in my current working draft. > > > > From: [email protected] [mailto:[email protected]] On Behalf Of John > Bradley > Sent: Wednesday, September 04, 2013 3:36 PM > To: George Fletcher > Cc: Richard Barnes; Jim Schaad; Anders Rundgren; Mike Jones; [email protected]; > Justin Richer > Subject: Re: [jose] #59: Allow direct signing and align with AAD > > > > I agree with George. > > > > I think the proposed change adds complexity rather than removing it by > signing the unencoded payload in some cases. I am also not a big fan of > unprotected headers though I am not bitter about it:) > > > > John B. > > > > > > > > On 2013-08-29, at 8:30 AM, George Fletcher <[email protected]> wrote: > > > > I'm also not seeing the value of this special case and how it makes the > understanding or coding easier? Doing things consistently the same way is > much simpler (from a complexity perspective) than having special cases (in > my judgement) even if it means a couple extra lines of code:) > > Thanks, > George > > On 8/29/13 11:15 AM, Richard Barnes wrote: > > 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 > > > > -- > <XeC.png> > > _______________________________________________ > jose mailing list > [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
