Subject: Re: [jose] #59: Allow direct signing and align with AAD

From: John Bradley <[email-masked]>
Date: Wed, 4 Sep 2013 15:36:08 -0700

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-masked]> 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-masked]> 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-masked]> 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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> >     >
>>> >     >     #59: Allow direct signing and align with AAD
>>> >     >
>>> >     >
>>> >     >     Comment (by [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>):
>>> >     >
>>> >     >      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-masked]   |       Owner:  draft-ietf-jose-json-web-
>>> >     >          Type:  defect       |  [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> >     >      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-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> >     >     https://www.ietf.org/mailman/listinfo/jose
>>> >     >
>>> >     >
>>> >     >
>>> >     >
>>> >     > _______________________________________________
>>> >     > jose mailing list
>>> >     > [email-masked] <mailto:[email-masked]>
>>> >     > https://www.ietf.org/mailman/listinfo/jose
>>> >     >
>>> >
>>> >
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> jose mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> -- 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Sep 2013 01:02:49 +0000

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-masked] [mailto:[email-masked]] 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-masked]; Justin Richer
Subject: Re: [jose] #59: Allow direct signing and align with AAD

I agree with George.

John B.

On 2013-08-29, at 8:30 AM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
George

--Richard

On Thu, Aug 29, 2013 at 10:50 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> 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 Wed, Aug 28, 2013 at 4:10 PM, Anders Rundgren <[email-masked]<mailto:[email-masked]>> wrote:

Cheers
Anders

>
>
> On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>                             "Subject": "CN=example.com<http://example.com/> <http://example.com<http://example.com/>>,O=Example Organization,C=US"
>                           },
>                         "X509CertificatePath":
>                           [
>     > On Wed, Aug 28, 2013 at 3:13 PM, jose issue tracker <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >
>     >     Comment (by [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>):
>     >
>     >      Reporter:  [email-masked]<mailto:[email-masked]>   |       Owner:  draft-ietf-jose-json-web-
>     >          Type:  defect       |  [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

jose mailing list

[email-masked]<mailto:[email-masked]>

jose mailing list

[email-masked]<mailto:[email-masked]>

--
<http://connect.me/gffletch>
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 4 Sep 2013 22:03:51 -0700

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-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Wednesday, September 04, 2013 6:03 PM
To: Richard Barnes
Cc: [email-masked]
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 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 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-masked] [mailto:[email-masked]] 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-masked];
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.

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

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

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 

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.

    }

      if (aad.length > 0) 

    }

The proposal collapses these two into one function, which happens to have an
"if" statement.

       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-masked]> wrote:

Cheers
Anders

>
>
> On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren
<[email-masked] <mailto:[email-masked]>>
wrote:
>     > This is not that.  Both of those issues had to do with the
representation of the signature in the message.
>     No chance that Enveloped JSON Signatures meet your requirements?
http://webpki.org/papers/keygen2/doc/org/webpki/json/package-summary.html#pa
ckage_description
>                          "Algorithm":
"http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
>                      "SignatureValue":
"B4N8pJI+Jwbw7nnb5UDtcR3WCpLloibVKNYJe+viCf4"
>                          "Algorithm":
"http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
>                      "SignatureValue":
"NvQzP+9hYtb5rfR2oZLbwq8dmi291gzc6Tc49FCOnCI"
>                     "Algorithm":
"http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256",

>                             "Subject": "CN=example.com
<http://example.com/>  <http://example.com <http://example.com/> >,O=Example
Organization,C=US"

>                         "X509CertificatePath":
"MIIClzCCAX+gAwIBAgIGAUDGIccKMA0GCSqGSIb3DQEBCwUAMEMxEzARBgoJkiaJk/IsZAEZFgN
NBCXhHSxoPVyBzv0lIgaO0ixD+q5P2OszRBYG3uk9W/uNIHdoyQn19w",
"MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJomT8ixkARkWA29yZzE
l1+ASbZX/r0/fNANLzXt/cnf0VXPrWdqvhuUSO561TsbTYg4qzcyDRV5vpjoUAxjFna06TJkeZR/
OYMMcTtPRJON3/bMvzp7MFoL20PRPxu8nnqxwLWNzoQCkExS2yWHq1YDNNL4C/PIuyC/2IUbbPuw
Np8ir3MVDBq4QwuXbw6xFvbPsxOmZyH10xvpsnmokg",
"MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRY
X4omlilZqTkTq6lBmDOdN+5RyBoA28EV+stt3+NV1JzOxIFqEqJfMW1q4Bzg5RM/S4xy/jCj/hMS
n2Etm5YoNVwju2L86JZ8433SoemQWjl7qMHEJ1tTMEG9hR5DiE9j6STtbza+WbJHGqSdY/z1IsYb
NgoZgYtJbRtZ4aObZb4FxflMTvObXiOInYgeKdK+Dw"
>                 "SignatureValue":
"MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neRqWjLv99t/WceE
kRBFZkRxaVz2/GBLzaOw"

>     > On Wed, Aug 28, 2013 at 3:13 PM, jose issue tracker
<[email-masked] <mailto:[email-masked]>
<mailto:[email-masked]
<mailto:[email-masked]> >
<mailto:[email-masked]
<mailto:[email-masked]>
<mailto:[email-masked]

>     >     Comment (by [email-masked]
<mailto:[email-masked]> <mailto:[email-masked]

>     >          Type:  defect       |  [email-masked]
<mailto:[email-masked]> <mailto:[email-masked]
<mailto:[email-masked]>>

>     >     Ticket URL:
<http://tools.ietf.org/wg/jose/trac/ticket/59#comment:2>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 5 Sep 2013 10:15:11 -0400

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-masked]> wrote:

> ****
> ** **
> ToBeSigned = base64url(Protected JWS Header) || “.” || base64url(Payload)*
> ***
>
> ** **
>
> ToBeAad = base64url(Protected JWE Header) || “.” || base64url(aad)****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Wednesday, September 04, 2013 6:03 PM
> *To:* Richard Barnes
> *Cc:* [email-masked]
>
> *Subject:* Re: [jose] #59: Allow direct signing and align with AAD****
>
> ** **
>
> 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
> )****
>
> ** **
>
> ****
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-15#section-5.2step 14.)
> ****
>
> ** **
>
> 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***
> *
>
> ** **
>
> 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-masked] [mailto:[email-masked]<[email-masked]>]
> *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-masked]; Justin Richer
> *Subject:* Re: [jose] #59: Allow direct signing and align with AAD****
>
> ** **
>
> I agree with George.****
>
> ** **
>
> unprotected headers though I am not bitter about it:)****
>
> ** **
>
> John B.****
>
> ** **
>
> ** **
>
> ** **
>
> On 2013-08-29, at 8:30 AM, George Fletcher <[email-masked]> wrote:****
>
> ** **
>
> 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.****
>
> ** **
>
> should be more general as well.****
>
> ** **
>
> --Richard****
>
> ** **
>
> ****
>  -- Justin ****
> ** **
> On 08/28/2013 04:24 PM, Richard Barnes wrote:****
>
> implementation that does both JWS and JWE.   ****
>
> ** **
>
> (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; ****
>
>     }****
>
> ** **
>
> similar things the same way.****
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Aug 28, 2013 at 4:10 PM, Anders Rundgren <
> [email-masked]> wrote:****
>
> > Nope, sorry.  This issue calls for a change to JWS/JWE, not something
> else.****
>
> Anders****
> > On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren <
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >                          "Algorithm": "
> http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
> >                          "Reference":
> >                            {
> >                              "Name": "ID",
> >                              "Value": "this"
> >                            },
> >                          "KeyInfo":
> >                            {
> >                              "KeyID": "symmetric-key"
> >                            }
> >                        },
> >                      "SignatureValue":
> >                          "Algorithm": "
> http://www.w3.org/2001/04/xmldsig-more#hmac-sha256",
> >                          "Reference":
> >                            {
> >                              "Name": "ID",
> >                              "Value": "that"
> >                            },
> >                          "KeyInfo":
> >                            {
> >                              "KeyID": "symmetric-key"
> >                            }
> >                        },
> >                      "SignatureValue":
> >                     "Algorithm": "
> http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256",
> >                     "Reference":
> >                       {
> >                         "Name": "ID",
> >                             "SerialNumber": 1377713637130,****
>
> >                             "Subject": "CN=example.com <
> http://example.com>,O=Example Organization,C=US"****
>
> >                           },
> >                         "X509CertificatePath":
> >                           [
> >
> "MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neRqWjLv99t/WceEkRBFZkRxaVz2/GBLzaOw"
> >               },
> >     >****
> >     > On Wed, Aug 28, 2013 at 3:13 PM, jose issue tracker <
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:
> [email-masked]>>> wrote:
> >     >
> >     >****
> >     >     Comment (by [email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>):****
>
> >     >
> >     >      Reporter:  [email-masked]   |       Owner:
>  draft-ietf-jose-json-web-****
>
> >     >          Type:  defect       |  [email-masked] <mailto:
> [email-masked]> <mailto:[email-masked] <mailto:
> [email-masked]>>****
>
> >     >     Ticket URL: <
> http://tools.ietf.org/wg/jose/trac/ticket/59#comment:2>
> >     >     jose mailing list****
> >     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]<mailto:
> [email-masked]>>****
>
> >     > jose mailing list****
> >****
> ** **
> ** **
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
> ** **
>
>
>
> ****
>
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>
> --
>  <http://connect.me/gffletch>****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 5 Sep 2013 18:16:22 +0000

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-masked]]
Sent: Thursday, September 05, 2013 7:15 AM
To: Jim Schaad
Cc: Mike Jones; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mike Jones
Sent: Wednesday, September 04, 2013 6:03 PM
To: Richard Barnes
Cc: [email-masked]<mailto:[email-masked]>

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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-masked]<mailto:[email-masked]>; Justin Richer
Subject: Re: [jose] #59: Allow direct signing and align with AAD

I agree with George.

John B.

Thanks,
George

--Richard

 -- Justin

Cheers
Anders

jose mailing list

jose mailing list

---

From: Brian Campbell <[email-masked]>
Date: Fri, 6 Sep 2013 15:01:11 -0700

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-masked]> 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.
>
>
>
> 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
>
>
>
> An illustration: Suppose you have the encoded header
> eyJhbGciOiJIUzI1NiIsIm9oIjoiY29tZV9vbiJ9Cg, and the empty string for the
> payload/aad
>
> encoding of the [protectedHeader], (2) a period (".") character, and (3) the
> base64url encoding of the [payload/aad].
>
> """
>
>
>
> In other words:
>
> Is there anyone here who finds that one "if" statement complex or ambiguous?
> If not, I don't understand what we're arguing about.
>
>
>
>
>
>
>
>
>
>
>
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-15#section-7.2.)
>
>
>
>> else.
>> <http://example.com>,O=Example Organization,C=US"
>
>>                           },
>>                         "X509CertificatePath":
>>                           [
>>
>> <mailto:[email-masked]>>> wrote:
>>     >
>> draft-ietf-jose-json-web-
>

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 6 Sep 2013 23:08:56 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, September 6, 2013 3:01 PM
To: Mike Jones
Cc: Richard Barnes; Jim Schaad; [email-masked]
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-masked]> 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.
>
>
>
>                 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.
>
>
>
> 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.)
>
>
>
> Mike
> 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:
>
> """
>
> [in Sec5.2] Let the Additional Authenticated Data encryption parameter 
> be the octets of the ASCII representation of the Encoded JWE Header value.
> 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:
>
>
>
> 2. The JWE encryption and decryption routines use inconsistent 
> definitions of "Additional Authenticated Data"
>
>
>
> eyJhbGciOiJIUzI1NiIsIm9oIjoiY29tZV9vbiJ9Cg, and the empty string for 
> the payload/aad
>
> The proposal in ISSUE-59 resolves these inconsistencies by changing 
> all of the above to something equivalent to the following:
>
> """
>
> encoding of the [protectedHeader], (2) a period (".") character, and 
> (3) the base64url encoding of the [payload/aad].
>
> """
>
>
>
> In other words:
>
> 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.
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mike Jones
> 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 concatenation of the Encoded JWS Header, a period ('.') 
> character, and the Encoded JWS Payload."  (See
> "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
> 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.
>
>
>
> 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.
>
>
>
>
>
>
>
> 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
>
> algorithm doesn't change anything.  Likewise for the JSON case with 
> any protected header (even if there are some unprotected headers).
>
>
>
> 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
>
>
>
> 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
>
>
>
> 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.
>
>
>
> reduction! :) ) and reducing the probability of interop problems by 
> doing similar things the same way.
>
>
>
>
>
>
>
> 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.
>
>> "MIIClzCCAX+gAwIBAgIGAUDGIccKMA0GCSqGSIb3DQEBCwUAMEMxEzARBgoJkiaJk/Is
>> ZAEZFgNvcmcxFjAUBgoJkiaJk/IsZAEZFgZ3ZWJwa2kxFDASBgNVBAMTC0RlbW8gU3ViI
>> ENBMB4XDTEyMDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowQjELMAkGA1UEBhMCVVMxHT
>> AbBgNVBAoTFEV4YW1wbGUgT3JnYW5pemF0aW9uMRQwEgYDVQQDEwtleGFtcGxlLmNvbTB
>> ZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABECkenu7FrOpy7J2FGeO1vrtseQqJT2GsaEx
>> xK5UVKe1zhFXjF+V8OFjv/FdM9fqdqwkP/YUnx5epvvHh/+/cQWjXTBbMAkGA1UdEwQCM
>> AAwDgYDVR0PAQH/BAQDAgP4MB0GA1UdDgQWBBR4YF2UOnLWDhOPLLuXYZum7xLMajAfBg
>> NVHSMEGDAWgBRZXCF2vVvvaakHecbUVh7jS1yIVTANBgkqhkiG9w0BAQsFAAOCAQEAjBu
>> ZK2TcDhib12DSW8rW3kyjfQ3iYtjNSVd7vJ5jyI+0OYQ/NlhN4vVJx7Z02vnrBxv1Nh9s
>> wgT5Jpw0724KawGC4P+/bUEvKVz89tPMl9DaV98yQ2YN4cBfhcW3FpAoI4dzBbCzfEpls
>> h9Ek7VxuIgwPozl0AdqOmTjZ3hh54ApSq/PMwENDyCEzD6bvrCrqCjgWSYIQUIvQ7LfO2
>> HAlEE9DcoV4mSl/8uiQ05hRdGmNYUHZVUua0HHX1h/nAS+IcS6/EDd89kEGrL3M92a5wq
>> nIQvDLO2NBCXhHSxoPVyBzv0lIgaO0ixD+q5P2OszRBYG3uk9W/uNIHdoyQn19w",
>>
>>
>> "MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJomT8ixkARkW
>> A29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEVMBMGA1UEAxMMRGVtbyBSb290IENBM
>> B4XDTA1MDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowQzETMBEGCgmSJomT8ixkARkWA2
>> 9yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEUMBIGA1UEAxMLRGVtbyBTdWIgQ0EwggE
>> iMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQI1w6lq0AsHbWMes8i/UGBeVQnlbz
>> L2N8VyLjkbT3HXNHPUTjWWQElhoRzFA2xPaH++V/ecgr2Dkievrm+B5yIsdAL4oWWmgZ9
>> KVMSfOrl5jy843p6AA55CHlP4j8v1uU1SpexIMUegDcNPlBwSRc0PPX+uqQ1STRg0kUgi
>> 4Bap7U5IRxTvp06adFXU4Bjr85ML7VZ3j+164t6mLnwF5RChJMlO7aVuz6TwxnWqeZytj
>> FOei742dgbX9SHPVvytLtbFp4V/VFoEhaOXLZiOudPvpVwVdlfgE0AtiGHEWrfA74BU5X
>> hME6UXzjcl3y3Ic304YGymo2jvmOwBki5wb3AgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBA
>> f8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRZXCF2vVvvaakHecbUVh7jS1yIVTAfBg
>> NVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAMlP
>> dBaZ/+AMDfFYI9SLQenx0/vludp0oN9BSDe+mTfYNp5nS131cZRCKMAR3g/zzgkULu022
>> xTJVsXfM1dsMYwEpGZp+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJRSUDGnoY6
>> 5g50dgv
>>
>> l1+ASbZX/r0/fNANLzXt/cnf0VXPrWdqvhuUSO561TsbTYg4qzcyDRV5vpjoUAxjFna06
>> l1+TJkeZR/OYMMcTtPRJON3/bMvzp7MFoL20PRPxu8nnqxwLWNzoQCkExS2yWHq1YDNNL
>> l1+4C/PIuyC/2IUbbPuwNp8ir3MVDBq4QwuXbw6xFvbPsxOmZyH10xvpsnmokg",
>>
>>
>> "MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQBGRYD
>> b3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwH
>> hcNMDIwNzEwMTAwMDAwWhcNMzAwNzEwMDk1OTU5WjBEMRMwEQYKCZImiZPyLGQBGRYDb3
>> JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwggE
>> iMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMR4ROlJJyBUzQ92XDSzFuxiMjwFqs
>> rKXuIksIXMypjg2QZF4PzyQ0pu32/LVKuoaqbT+bkRKFdpUvMKhzGQ3rMAthTUkhXpFJN
>> 5Bk2LTcGXoE0B9wPKn4C3cxbUMEtT94m8PKIjRoKm77Rvdd4vrG1GiCw98WriMtNbX/ps
>> Yzr/RikIcpEUpm4PPXzPPFuBzYIeDFG50aPEJu6arup5b1w7SQe6lq/f/XhKYWENH1LcQ
>> OFsMoQ8oUS/WsYQ8aeT6/FxjMumjv4f9LanUHb73bBPA0xiqtEfNIuK1ZogXgqT0157tq
>> bmg2+GCSz+dGZv3VbSyQPdqh5s8YEGEK873vAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBA
>> f8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRaQnES9aDCSV/XOklJczxnqxI4/DAfBg
>> NVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAHyx
>> u0Z74ZYbWdy/fUtI9uIid/7F5AjbDdTzJcZgbSvyF3ZYVF62pRjSyxtIcCKbbr/oRPf5v
>> oYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FTM1aCaJhu
>> 1RqioUK
>>
>> -------------------------+-------------------------------------------
>> -------------------------+------
>> -------------------------+-------------------------------------------
>> -------------------------+------
>>     >
>>     >     Ticket URL:

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 6 Sep 2013 16:48:00 -0700

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

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Friday, September 06, 2013 4:09 PM
> To: Brian Campbell; Mike Jones
> 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.
> 
> 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.
> >             [JSI/AAD] = (protectedHeader)? base64url(protectedHeader) +
"."
> > + [payload/aad] : [payload/aad]
> >
> >
> >
> ambiguous?
> > ion-7.2.)
> > the value to be integrity protected.  They are (already) consistent with
one
> another.
> > Of John Bradley
serialization.
> > that? Seems we really should keep things parallel, which will itself
remove
> complexity.
> >> http://webpki.org/papers/keygen2/doc/org/webpki/json/package-
> summary.
> >> html#package_description
> >>
> X4omlilZqTkTq6lBmDOdN+5RyBoA28EV+stt3+NV1JzOxIFqEqJfMW1q4Bzg5R
> M/S4xy/jCj/hMSn2Etm5YoNVwju2L86JZ8433SoemQWjl7qMHEJ1tTMEG9hR5
> DiE9j6STtbza+WbJHGqSdY/z1IsYbNgoZgYtJbRtZ4aObZb4FxflMTvObXiOInYge
> KdK+Dw"
> >>                           ]
> >>                       }
> >>                   },
> >>                 "SignatureValue":
> >>
> >>     >      This largely seems to be an attempt to reopen issues #23
(Make
> >> crypto
> >>     >      payload to not be base64 encoded), both of which were
already
> >> closed as
> >>     >      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.

---

From: Mike Jones <[email-masked]>
Date: Fri, 6 Sep 2013 23:53:47 +0000

This also makes sense to me.

Have a good weekend, everyone!

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Friday, September 06, 2013 4:48 PM
To: Anthony Nadalin; 'Brian Campbell'; Mike Jones
Cc: 'Richard Barnes'; [email-masked]
Subject: RE: [jose] #59: Allow direct signing and align with AAD

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

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

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

not a
> Of Brian Campbell
> signature
and
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.
> 
> this
issue
"."
> > 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.
> > [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 ('.') 
> > 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.
> >
> >
> >
> > is present in the JWE.  The intent of this note is to clarify this 
> > point
of fact.
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-15#sec
> > ti
> > on-2)
> >
> >
> >
> > The JWE Additional Authenticated Data encryption parameter is 
> > computed
> as:
> >
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.)
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> > 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
> >
serialization.
> > 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
> > JWS Signing Input and the JWE Authenticated Data, even though 
> > they're both (header + data) inputs to integrity protection.
> >
> >
> >
> > Cramming a lot of functionality into JWS may render as useless as 
> > you claim that XML DSig is.
> >
> > I still see great value in JWS and in fact already use it with 
> > Google
apps.
(Make
already
rather
requested
duplicate
> >> of #26.
> >>     >
> >>     >     --
> >>     >
> >> -------------------------+-----------------------------------------
> >> -------------------------+--
> >> -------------------------+-----------------------------------------
> >> -------------------------+--

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Sep 2013 12:03:31 -0400

Sorry, I should have been clearer.  I was envisioning a constrained
implementation that would not support protected headers.  Because as I've
said before, there is no cryptographic necessity for protected headers
except PSS, which is probably to heavy-weight for constrained
implementations anyway.

--Richard

On Mon, Sep 9, 2013 at 11:54 AM, Jim Schaad <[email-masked]> wrote:

> Sorry Richard,****
>
> ** **
>
> Without the base64url of at least half of the signing string there is a
> security problem of things moving back and forth between the two halves of
> the data.  This would be different if the decision had been to use length
> prefixed strings but that is not the case.****
>
> ** **
>
> I want to sign what I send, and for the “I don’t base64 encode the
> payload” that means that I absolutely must be able to determine where the
> first half ends and the second half begins in such a way as to ensure there
> is no cross over between the two sides.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Monday, September 09, 2013 8:44 AM
> *To:* Jim Schaad
> *Cc:* Anthony Nadalin; Brian Campbell; Mike Jones; [email-masked]
>
> This issue isn't incompatible with issue-26 at all.  The part of issue-26
> you're talking about is just a serialization question, which is independent
> from the question of what octet string is signed.****
>
> ** **
>
> This issue actually addresses a different forward-compatibility problem.
>  If we ever want to have an implementation that does not require base64,
> then we need to have a signature mode where base64 is not required.
>  Imagine a constrained device using a CBOR serialization, which has devoted
> a lot of its valuable code space to crypto.  There's no technical need for
> base64, because CBOR supports octet strings, and the additional space for
> base64 code is valuable, not to mention the storage requirements to keep
> both the encoded and unencoded forms around.  We even have existing text in
> the Use Cases document for this:****
>
> """****
>
> [[ In "Object security for CoAP": ]] The size of the secure object shall
> be as small as possible.****
>
> F8 Do not impose more overhead than is required to meet the****
>
>       requirements in this document, especially when a large amount of****
>
>       application content is being protected.****
>
> ...****
>
> D3 Maximize the extent to which the inputs and outputs of JOSE****
>
>       cryptographic operations can be controlled by the applications, as**
> **
>
>       opposed to involving processing specific to JOSE.****
>
> """****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Sep 6, 2013 at 7:48 PM, Jim Schaad <[email-masked]> wrote:
> ****
>
> Jim****
> > Cc: Richard Barnes; Jim Schaad; [email-masked]****
>
> > > out that equations make this much simpler to compare and decide if it
> is
> > wrong.
> > >
> > >
> > >
> > >>     >      "wontfix".  In particular, both of the already-closed
> issues
> > >> proposed

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 9 Sep 2013 08:54:02 -0700

Sorry Richard,

Without the base64url of at least half of the signing string there is a
security problem of things moving back and forth between the two halves of
the data.  This would be different if the decision had been to use length
prefixed strings but that is not the case.

I want to sign what I send, and for the “I don’t base64 encode the payload”
that means that I absolutely must be able to determine where the first half
ends and the second half begins in such a way as to ensure there is no cross
over between the two sides.

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, September 09, 2013 8:44 AM
To: Jim Schaad
Cc: Anthony Nadalin; Brian Campbell; Mike Jones; [email-masked]
Subject: Re: [jose] #59: Allow direct signing and align with AAD

This issue isn't incompatible with issue-26 at all.  The part of issue-26
you're talking about is just a serialization question, which is independent
from the question of what octet string is signed.

This issue actually addresses a different forward-compatibility problem.  If
we ever want to have an implementation that does not require base64, then we
need to have a signature mode where base64 is not required.  Imagine a
constrained device using a CBOR serialization, which has devoted a lot of
its valuable code space to crypto.  There's no technical need for base64,
because CBOR supports octet strings, and the additional space for base64
code is valuable, not to mention the storage requirements to keep both the
encoded and unencoded forms around.  We even have existing text in the Use
Cases document for this:

"""

[[ In "Object security for CoAP": ]] The size of the secure object shall be
as small as possible.

F8 Do not impose more overhead than is required to meet the

      requirements in this document, especially when a large amount of

      application content is being protected.

...

D3 Maximize the extent to which the inputs and outputs of JOSE

      cryptographic operations can be controlled by the applications, as

      opposed to involving processing specific to JOSE.

"""

--Richard

 

Currently you have

Jim

not a
and
is
issue
"."
one
serialization.
remove

(Make
already
rather
requested
duplicate

---

From: Richard Barnes <[email-masked]>
Date: Mon, 9 Sep 2013 11:44:04 -0400

the Use Cases document for this:

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Sep 2013 17:03:03 -0700

I understand this as a reasonable use case.  And I am perfectly willing to
burn the period for the instance where the same set of constrained devices
all of a sudden decide that that need to have the protected headers.  This
does not require that they implement the base64url just emit the period
until that is a true situation.

At the point they decide they need to do protected headers, it needs to be
possible for them to do so.

Jim

From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, September 09, 2013 9:04 AM
To: Jim Schaad
Cc: Anthony Nadalin; Brian Campbell; Mike Jones; [email-masked]
Subject: Re: [jose] #59: Allow direct signing and align with AAD

--Richard

Sorry Richard,

Jim

"""

...

"""

--Richard

 

Currently you have

Jim

not a
and
is
issue
"."
one
serialization.
remove

(Make
already
rather
requested
duplicate