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

From: "jose issue tracker" <[email-masked]>
Date: Sun, 11 Aug 2013 22:59:51 -0000

#59: Allow direct signing and align with AAD

 When no protected header is present, the JWS Signing Input is currently
 the payload with some extra junk (base64url encoded, prepended with a
 ".").  In this case, the signing input (JWS) should simply be the payload
 (without encoding/prepending).  This allows developers more direct control
 over the inputs to cryptographic algorithms, and thus more flexibility in
 the cryptographic protocols they can implement with JWS.  A minor risk is
 introduced, in that

 Regardless of the resolution of the above, the construction of the AAD
 field for JWE should be the same as the construction of the JWS Signing
 Input.  They both construct a value to be integrity protected out of (1) a
 protected header, and (2) direct application input (payload/"aad").

-- 
-------------------------------------+-------------------------------------
 Reporter:  [email-masked]               |      Owner:  draft-barnes-jose-use-
     Type:  defect                   |  [email-masked]
 Priority:  major                    |     Status:  new
Component:  draft-barnes-jose-use-   |  Milestone:
  cases                              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: "jose issue tracker" <[email-masked]>
Date: Sun, 18 Aug 2013 19:52:37 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] => draft-ietf-jose-
     [email-masked]
 * component:  draft-barnes-jose-use-cases => json-web-signature

-- 
-------------------------+-------------------------------------------------
 Reporter:  [email-masked]   |       Owner:  draft-ietf-jose-json-web-
     Type:  defect       |  [email-masked]
 Priority:  major        |      Status:  new
Component:  json-web-    |   Milestone:
  signature              |     Version:
 Severity:  -            |  Resolution:
 Keywords:               |
-------------------------+-------------------------------------------------

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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 20 Aug 2013 10:46:10 -0400

For all the discussion of "additional complexity", it takes 3 lines to
implement this change in PyJOSE:

OLD:
def createSigningInput(header, payload):
    return header + "." + payload

NEW:
def createSigningInput(header, payload):
    if len(header) == 0 or len(json.loads(header)) == 0:
        return b64dec(payload)
    else:
        return header +"."+ payload

On Sun, Aug 18, 2013 at 3:52 PM, jose issue tracker <
[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: "jose issue tracker" <[email-masked]>
Date: Wed, 28 Aug 2013 19:13:11 -0000

Comment (by [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.

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 15:30:59 -0400

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.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 28 Aug 2013 21:40:26 +0200

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,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+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJRSUDGnoY6
 5g50dgv
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/oRPf5voYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FTM1aCaJhu
 1RqioUK
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]>> wrote:
> 
>     Comment (by [email-masked] <mailto:[email-masked]>):
> 
>          Type:  defect       |  [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 15:46:04 -0400

Nope, sorry.  This issue calls for a change to JWS/JWE, not something else.

On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren <
[email-masked]> wrote:

> > This is not that.  Both of those issues had to do with the
> representation of the signature in the message.
>                      "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"
>                }
>            }],
>                 "Algorithm": "
> http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256",
>                 "Reference":
>                   {
>                     "Name": "ID",
> "MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEVMBMGA1UEAxMMRGVtbyBSb290IENBMB4XDTA1MDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowQzETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEUMBIGA1UEAxMLRGVtbyBTdWIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQI1w6lq0AsHbWMes8i/UGBeVQnlbzL2N8VyLjkbT3HXNHPUTjWWQElhoRzFA2xPaH++V/ecgr2Dkievrm+B5yIsdAL4oWWmgZ9KVMSfOrl5jy843p6AA55CHlP4j8v1uU1SpexIMUegDcNPlBwSRc0PPX+uqQ1STRg0kUgi4Bap7U5IRxTvp06adFXU4Bjr85ML7VZ3j+164t6mLnwF5RChJMlO7aVuz6TwxnWqeZytjFOei742dgbX9SHPVvytLtbFp4V/VFoEhaOXLZiOudPvpVwVdlfgE0AtiGHEWrfA74BU5XhME6UXzjcl3y3Ic304YGymo2jvmOwBki5wb3AgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRZXCF2vVvvaakHecbUVh7jS1yIVTAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAMlPdBaZ/+AMDfFYI9SLQenx0/vludp0oN9BSDe+mTfYNp5nS131cZRCKMAR3g/zzgkULu022xTJVsXfM1dsMYwEpGZp+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJRSUDGnoY65g50dgv
>
> "MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwHhcNMDIwNzEwMTAwMDAwWhcNMzAwNzEwMDk1OTU5WjBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMR4ROlJJyBUzQ92XDSzFuxiMjwFqsrKXuIksIXMypjg2QZF4PzyQ0pu32/LVKuoaqbT+bkRKFdpUvMKhzGQ3rMAthTUkhXpFJN5Bk2LTcGXoE0B9wPKn4C3cxbUMEtT94m8PKIjRoKm77Rvdd4vrG1GiCw98WriMtNbX/psYzr/RikIcpEUpm4PPXzPPFuBzYIeDFG50aPEJu6arup5b1w7SQe6lq/f/XhKYWENH1LcQOFsMoQ8oUS/WsYQ8aeT6/FxjMumjv4f9LanUHb73bBPA0xiqtEfNIuK1ZogXgqT0157tqbmg2+GCSz+dGZv3VbSyQPdqh5s8YEGEK873vAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRaQnES9aDCSV/XOklJczxnqxI4/DAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAHyxu0Z74ZYbWdy/fUtI9uIid/7F5AjbDdTzJcZgbSvyF3ZYVF62pRjSyxtIcCKbbr/oRPf5voYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FTM1aCaJhu1RqioUK
>
>             "SignatureValue":
> "MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neRqWjLv99t/WceEkRBFZkRxaVz2/GBLzaOw"
>           },
> [email-masked] <mailto:[email-masked]>>
> wrote:
> >

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 28 Aug 2013 22:10:31 +0200

> 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:
> 
>                             "Subject": "CN=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]>>> wrote:
>     >
>     >     Comment (by [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>):
>     >
>     >          Type:  defect       |  [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Aug 2013 16:24:11 -0400

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:

> [email-masked] <mailto:[email-masked]>>
> wrote:
> >
> >                             "Subject": "CN=example.com <
> http://example.com>,O=Example Organization,C=US"
> >                           },
> >                         "X509CertificatePath":
> >                           [
> >
> [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]>>):
> >     >
> >     >          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>
> >     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]<mailto:
> [email-masked]>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Aug 2013 21:05:07 +0000

Currently the JWS Signing Input is always computed the same way
                JWS Signing Input = Encoded JWS Protected Header | '.' | Encoded JWS Payload.
That's simple and implementers will get it right.

What you're proposing is that the computation would instead be:
                JWS Signing Input =
                                If JWS Protected Header exists
                                                Encoded JWS Protected Header | '.' | Encoded JWS Payload
                                Else
                                                JWS Payload
That's not as simple and there's a greater chance for resulting interop problems.

Besides, the parallelism you're after with JWE in the case where an "aad" member is present is already in place.  That computation is:
                JWE Integrity Input = Encoded JWE Protected Header | '.' | Encoded AAD Value.

Your code below is wrong because it appears to be appending the unencoded aad value - not the base64url encoded AAD value.  The treatment of the JWS and JWE integrity values are already parallel.

Finally, as for size arguments for constrained devices, the JWS integrity value calculation is already optimized for space, because to create the compact serialization, the implementation already has to create the value "Encoded JWS Protected Header | '.' | Encoded JWS Payload" as part of the JWS representation.  No extra space required.

Again, I see the core of this request as being another stab at getting the spec changed to use unencoded payloads in the integrity calculation - which we already addressed in issue #26.  This should be closed as "wontfix" for the same reason.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, August 28, 2013 1:24 PM
To: Anders Rundgren
Cc: Jim Schaad; Mike Jones; [email-masked]
Subject: Re: [jose] #59: Allow direct signing and align with AAD

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.

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

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]<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>,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]>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 29 Aug 2013 10:50:50 -0400

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.
>
> 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] <mailto:[email-masked]>> 
> wrote:
>
>     > On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren
>     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[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",
>     >                             "Subject": "CN=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]>>>):
>     >     >
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     >     Ticket URL:
>     <http://tools.ietf.org/wg/jose/trac/ticket/59#comment:2>
>     >     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 29 Aug 2013 11:15:58 -0400

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:

> 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
>
>
>>  >     >          Type:  defect       |  [email-masked]<mailto:
> jose mailing [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Aug 2013 15:22:56 +0000

The primary problem with the proposal is that it makes signature computations within the JSON serialization inconsistent by introducing an unneeded special case.  Let's keep things simpler by always computing the signatures the same way.  There's no compelling reason to have the special case at all.

                                                            -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, August 29, 2013 8:16 AM
To: Justin Richer
Cc: Anders Rundgren; Jim Schaad; Mike Jones; [email-masked]
Subject: Re: [jose] #59: Allow direct signing and align with AAD

Not quite.  The compact serialization is a subset of the JSON serialization.  For both the compact case and the equivalent JSON case, the proposed algorithm doesn't change anything.  Likewise for the JSON case with any protected header (even if there are some unprotected headers).

The only change is when there is no protected header, which can only happen in the JSON case.

So the change only occurs for a subset of JSON cases.  But that sort of makes sense -- the JSON format is more general, so the signing algorithm should be more general as well.

--Richard

On Thu, Aug 29, 2013 at 10:50 AM, Justin Richer <[email-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

Cheers
Anders

jose mailing list

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

---

From: George Fletcher <[email-masked]>
Date: Thu, 29 Aug 2013 11:30:41 -0400

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:
> 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).
>
> 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.
>>
>>         function
>>     createJWEAuthenticatedData(serializedProtectedHeader, aad) {
>>           if (aad.length > 0)
>>     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.
>>
>>
>>
>>
>>     <mailto:[email-masked]>> 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,
>>         >
>>         >     >      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] <mailto:[email-masked]>>>
>>         <mailto:[email-masked] <mailto:[email-masked]>>
>>     _______________________________________________ jose mailing list

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 29 Aug 2013 12:16:12 -0400

"Inconsistency" actually cuts the other way.  "Inconsistency" is when you
do the same thing two ways.  The current specs are inconsistent between JWE
and JWS in terms of how the integrity-protected data are computed (JWS
Signing Input vs. AAD).  The proposal is to make the specs *consistent* in
this regard, and to do different two things (protected+payload vs. payload)
different ways.

As I said at the IETF meeting, there are a few compelling reasons, namely:
We maximize the set of apps that can use JOSE by not mixing JOSE-specific
stuff into the crypto.

--Richard

On Thu, Aug 29, 2013 at 11:22 AM, Mike Jones <[email-masked]>wrote:

>  The primary problem with the proposal is that it makes signature
> computations within the JSON serialization inconsistent by introducing an
> unneeded special case.  Let’s keep things simpler by always computing the
> signatures the same way.  There’s no compelling reason to have the special
> case at all.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Thursday, August 29, 2013 8:16 AM
> *To:* Justin Richer
> *Cc:* Anders Rundgren; Jim Schaad; Mike Jones; [email-masked]
> *Subject:* Re: [jose] #59: Allow direct signing and align with AAD****
>
> ** **
>
> 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****
>
> ** **
>
> ****
> 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
>  -- 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;****
>
>     }****
>
> ** **
>
> an "if" statement.****
> ** **
>     function createSigningInput(serializedProtectedHeader, payload) {****
>
>        if (serializedProtectedHeader.length > 0) ****
>
>          return b64enc(serializedProtectedHeader) +'.'+ b64enc(payload)***
> *
>
>        else return payload; ****
>
>     }****
>
> ** **
>
> similar things the same way.****
>
> ** **
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> > Nope, sorry.  This issue calls for a change to JWS/JWE, not something
> else.****
>
> Anders****
> >                             "SerialNumber": 1377713637130,****
>
> http://example.com>,O=Example Organization,C=US"****
>
> >                           },
> >                         "X509CertificatePath":
> >                           [
> >
> >     >****
> >     >****
> [email-masked]>>):****
>
> >     >
> >     >      Reporter:  [email-masked]   |       Owner:
>  draft-ietf-jose-json-web-****
>
> [email-masked]>>****
>
> >     >     jose mailing list****
> [email-masked]>>****
> >     > jose mailing list****
> >****
> ** **
> ** **
> _______________________________________________****
>
> jose mailing list****
>
> [email-masked]****
>
>  https://www.ietf.org/mailman/listinfo/jose****
>
>  ** **
>
> ** **
>