I agree that this item should be closed, but my reasons are not currently acceptable to the WG as a whole. I don't want this behavior because I believe that it will close off the possible later incorporation of Issue #26 - Allow for signature payload not to be base64 encoded.
Currently you have ToBeSigned = base64url(Protected Headers) || "." || base64url(payload) ToBeAuthenticated = base64url(Protected Headers) If (aad) ToBeAuthenticated = ToBeAuthenticated || "." || base64url(aad) In the event that Issue #26 were adopted in a future draft, you would be able to do ToBeSigned = base64url(Protected Headers) || "." || payload ToBeAuthenticated = base64url(Protected Headers) If (aad) ToBeAuthenticated = ToBeAuthenticated || "." || aad In both of these cases the fact that the first element, even if a zero length string, exists and is terminated by a period character means that there is a well-known stopping point for the first field and a well-known starting point for the second field. For the authenticated headers, the absence of the period means that the aad field does not exist so there is no ambiguity. If the first field and the period were optional that would not be case for the ToBeSigned. It would be more a case of parallelism if one could omit the payload rather than omitting the protected headers. Jim > -----Original Message----- > From: Anthony Nadalin [mailto:[email protected]] > Sent: Friday, September 06, 2013 4:09 PM > To: Brian Campbell; Mike Jones > Cc: Richard Barnes; Jim Schaad; [email protected] > Subject: RE: [jose] #59: Allow direct signing and align with AAD > > Agree that this should be closed, I'm just not convinced that this is just not a > very special case that will cause unnecessary changes. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Brian Campbell > Sent: Friday, September 6, 2013 3:01 PM > To: Mike Jones > Cc: Richard Barnes; Jim Schaad; [email protected] > Subject: Re: [jose] #59: Allow direct signing and align with AAD > > 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#secti > > on-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#sect > > ion-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#sect > > ion-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+gAwIBAgIGAUDGIccKMA0GCSqGSIb3DQEBCwUAMEMxEzARB > goJkiaJk/Is > >> > ZAEZFgNvcmcxFjAUBgoJkiaJk/IsZAEZFgZ3ZWJwa2kxFDASBgNVBAMTC0RlbW > 8gU3ViI > >> > ENBMB4XDTEyMDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowQjELM > AkGA1UEBhMCVVMxHT > >> > AbBgNVBAoTFEV4YW1wbGUgT3JnYW5pemF0aW9uMRQwEgYDVQQDEwtle > GFtcGxlLmNvbTB > >> > ZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABECkenu7FrOpy7J2FGeO1vrts > eQqJT2GsaEx > >> > xK5UVKe1zhFXjF+V8OFjv/FdM9fqdqwkP/YUnx5epvvHh/+/cQWjXTBbMAkG > A1UdEwQCM > >> > AAwDgYDVR0PAQH/BAQDAgP4MB0GA1UdDgQWBBR4YF2UOnLWDhOPLLuX > YZum7xLMajAfBg > >> > NVHSMEGDAWgBRZXCF2vVvvaakHecbUVh7jS1yIVTANBgkqhkiG9w0BAQsFA > AOCAQEAjBu > >> > ZK2TcDhib12DSW8rW3kyjfQ3iYtjNSVd7vJ5jyI+0OYQ/NlhN4vVJx7Z02vnrBxv1 > Nh9s > >> > wgT5Jpw0724KawGC4P+/bUEvKVz89tPMl9DaV98yQ2YN4cBfhcW3FpAoI4dzB > bCzfEpls > >> > h9Ek7VxuIgwPozl0AdqOmTjZ3hh54ApSq/PMwENDyCEzD6bvrCrqCjgWSYIQU > IvQ7LfO2 > >> > HAlEE9DcoV4mSl/8uiQ05hRdGmNYUHZVUua0HHX1h/nAS+IcS6/EDd89kEGrL3 > M92a5wq > >> > nIQvDLO2NBCXhHSxoPVyBzv0lIgaO0ixD+q5P2OszRBYG3uk9W/uNIHdoyQn19 > w", > >> > >> > >> > "MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJo > mT8ixkARkW > >> > A29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEVMBMGA1UEAxMMRGVt > byBSb290IENBM > >> > B4XDTA1MDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowQzETMBEGCg > mSJomT8ixkARkWA2 > >> > 9yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEUMBIGA1UEAxMLRGVtbyBT > dWIgQ0EwggE > >> > iMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQI1w6lq0AsHbWMes8i > /UGBeVQnlbz > >> > L2N8VyLjkbT3HXNHPUTjWWQElhoRzFA2xPaH++V/ecgr2Dkievrm+B5yIsdAL4 > oWWmgZ9 > >> > KVMSfOrl5jy843p6AA55CHlP4j8v1uU1SpexIMUegDcNPlBwSRc0PPX+uqQ1ST > Rg0kUgi > >> > 4Bap7U5IRxTvp06adFXU4Bjr85ML7VZ3j+164t6mLnwF5RChJMlO7aVuz6Twxn > WqeZytj > >> > FOei742dgbX9SHPVvytLtbFp4V/VFoEhaOXLZiOudPvpVwVdlfgE0AtiGHEWrfA > 74BU5X > >> > hME6UXzjcl3y3Ic304YGymo2jvmOwBki5wb3AgMBAAGjYzBhMA8GA1UdEwE > B/wQFMAMBA > >> > f8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRZXCF2vVvvaakHecbUV > h7jS1yIVTAfBg > >> > NVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFA > AOCAQEAMlP > >> > dBaZ/+AMDfFYI9SLQenx0/vludp0oN9BSDe+mTfYNp5nS131cZRCKMAR3g/zzg > kULu022 > >> > xTJVsXfM1dsMYwEpGZp+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJ > RSUDGnoY6 > >> 5g50dgv > >> > >> > l1+ASbZX/r0/fNANLzXt/cnf0VXPrWdqvhuUSO561TsbTYg4qzcyDRV5vpjoUAxj > Fna06 > >> > l1+TJkeZR/OYMMcTtPRJON3/bMvzp7MFoL20PRPxu8nnqxwLWNzoQCkExS2y > WHq1YDNNL > >> > l1+4C/PIuyC/2IUbbPuwNp8ir3MVDBq4QwuXbw6xFvbPsxOmZyH10xvpsnmo > kg", > >> > >> > >> > "MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZP > yLGQBGRYD > >> > b3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIF > Jvb3QgQ0EwH > >> > hcNMDIwNzEwMTAwMDAwWhcNMzAwNzEwMDk1OTU5WjBEMRMwEQYK > CZImiZPyLGQBGRYDb3 > >> > JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJv > b3QgQ0EwggE > >> > iMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMR4ROlJJyBUzQ92XDSz > FuxiMjwFqs > >> > rKXuIksIXMypjg2QZF4PzyQ0pu32/LVKuoaqbT+bkRKFdpUvMKhzGQ3rMAthT > UkhXpFJN > >> > 5Bk2LTcGXoE0B9wPKn4C3cxbUMEtT94m8PKIjRoKm77Rvdd4vrG1GiCw98Wri > MtNbX/ps > >> > Yzr/RikIcpEUpm4PPXzPPFuBzYIeDFG50aPEJu6arup5b1w7SQe6lq/f/XhKYWEN > H1LcQ > >> > OFsMoQ8oUS/WsYQ8aeT6/FxjMumjv4f9LanUHb73bBPA0xiqtEfNIuK1ZogXgq > T0157tq > >> > bmg2+GCSz+dGZv3VbSyQPdqh5s8YEGEK873vAgMBAAGjYzBhMA8GA1UdEw > EB/wQFMAMBA > >> > f8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRaQnES9aDCSV/XOklJczx > nqxI4/DAfBg > >> > NVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFA > AOCAQEAHyx > >> > u0Z74ZYbWdy/fUtI9uIid/7F5AjbDdTzJcZgbSvyF3ZYVF62pRjSyxtIcCKbbr/oRPf > 5v > >> > oYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FT > M1aCaJhu > >> 1RqioUK > >> > >> > X4omlilZqTkTq6lBmDOdN+5RyBoA28EV+stt3+NV1JzOxIFqEqJfMW1q4Bzg5R > M/S4xy/jCj/hMSn2Etm5YoNVwju2L86JZ8433SoemQWjl7qMHEJ1tTMEG9hR5 > DiE9j6STtbza+WbJHGqSdY/z1IsYbNgoZgYtJbRtZ4aObZb4FxflMTvObXiOInYge > KdK+Dw" > >> ] > >> } > >> }, > >> "SignatureValue": > >> > "MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neR > qWjLv99t/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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
