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 protected] [mailto:[email protected]] On Behalf Of Richard
Barnes
Sent: Wednesday, August 28, 2013 1:24 PM
To: Anders Rundgren
Cc: Jim Schaad; Mike Jones; [email protected]
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.
function createJWSSigningInput(serializedProtectedHeader, payload) {
return b64enc(serializedProtectedHeader) +'.'+ b64enc(payload);
}
function createJWEAuthenticatedData(serializedProtectedHeader, aad) {
if (aad.length > 0)
return serializedProtectedHeader + "." + aad;
else return serializedProtectedHeader;
}
The proposal collapses these two into one function, which happens to have an
"if" statement.
function createSigningInput(serializedProtectedHeader, payload) {
if (serializedProtectedHeader.length > 0)
return b64enc(serializedProtectedHeader) +'.'+ b64enc(payload)
else return payload;
}
So we're actually saving lines of code here (9 lines to 5 -- a 44% reduction!
:) ) and reducing the probability of interop problems by doing similar things
the same way.
On Wed, Aug 28, 2013 at 4:10 PM, Anders Rundgren
<[email protected]<mailto:[email protected]>> wrote:
On 2013-08-28 21:46, Richard Barnes wrote:
> Nope, sorry. This issue calls for a change to JWS/JWE, not something else.
Maybe your use-case also calls for another solution?
Cramming a lot of functionality into JWS may render as useless as you claim
that XML DSig is.
I FWIW didn't see that a message-in-signature-scheme would be a suitable
replacement for my current XML-based signature-in-message system.
I still see great value in JWS and in fact already use it with Google apps.
Cheers
Anders
>
>
> On Wed, Aug 28, 2013 at 3:40 PM, Anders Rundgren
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
> wrote:
>
> On 2013-08-28 21:30, Richard Barnes wrote:
> > This is not that. Both of those issues had to do with the
> representation of the signature in the message.
> > Issue #59 is about what gets signed, and what it proposes is much more
> limited than the other two.
>
> Richard,
>
> No chance that Enveloped JSON Signatures meet your requirements?
>
>
> http://webpki.org/papers/keygen2/doc/org/webpki/json/package-summary.html#package_description
>
> Here you have an authentic example with three signatures:
>
> {
> "MyLittleSignature":
> {
> "Version": "http://example.com/signature";,
> "Now": "2013-08-28T21:27:22+02:00",
> "HRT":
> {
> "RTl": "67",
> "YT":
> {
> "HTL": "656756#",
> "INTEGER": -689,
> "Fantastic": false
> },
> "er": "33"
> },
> "ARR": [],
> "BARR":
> [{
> "HTL": "656756#",
> "INTEGER": -689,
> "Fantastic": true
> },
> {
> "HTL": "656756#",
> "INTEGER": -689,
> "Fantastic": false
> }],
> "SignedObjects":
> [{
> "ID": "this",
> "VALUE": 35,
> "EnvelopedSignature":
> {
> "SignatureInfo":
> {
> "Algorithm":
> "http://www.w3.org/2001/04/xmldsig-more#hmac-sha256";,
> "Reference":
> {
> "Name": "ID",
> "Value": "this"
> },
> "KeyInfo":
> {
> "KeyID": "symmetric-key"
> }
> },
> "SignatureValue":
> "B4N8pJI+Jwbw7nnb5UDtcR3WCpLloibVKNYJe+viCf4"
> }
> },
> {
> "ID": "that",
> "VALUE": -90,
> "EnvelopedSignature":
> {
> "SignatureInfo":
> {
> "Algorithm":
> "http://www.w3.org/2001/04/xmldsig-more#hmac-sha256";,
> "Reference":
> {
> "Name": "ID",
> "Value": "that"
> },
> "KeyInfo":
> {
> "KeyID": "symmetric-key"
> }
> },
> "SignatureValue":
> "NvQzP+9hYtb5rfR2oZLbwq8dmi291gzc6Tc49FCOnCI"
> }
> }],
> "ID": "cDl5MXhuHdh1CvMht9fc",
> "STRINGS": ["One","Two","Three"],
> "EscapeMe": "A\\\n\"",
> "Intra": 78,
> "EnvelopedSignature":
> {
> "SignatureInfo":
> {
> "Algorithm":
> "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256";,
> "Reference":
> {
> "Name": "ID",
> "Value": "cDl5MXhuHdh1CvMht9fc"
> },
> "KeyInfo":
> {
> "SignatureCertificate":
> {
> "Issuer": "CN=Demo Sub CA,DC=webpki,DC=org",
> "SerialNumber": 1377713637130,
> "Subject": "CN=example.com<http://example.com>
> <http://example.com>,O=Example Organization,C=US"
> },
> "X509CertificatePath":
> [
>
> "MIIClzCCAX+gAwIBAgIGAUDGIccKMA0GCSqGSIb3DQEBCwUAMEMxEzARBgoJkiaJk/IsZAEZFgNvcmcxFjAUBgoJkiaJk/IsZAEZFgZ3ZWJwa2kxFDASBgNVBAMTC0RlbW8gU3ViIENBMB4XDTEyMDEwMTAwMDAwMFoXDTIwMDcxMDA5NTk1OVowQjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGUgT3JnYW5pemF0aW9uMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABECkenu7FrOpy7J2FGeO1vrtseQqJT2GsaExxK5UVKe1zhFXjF+V8OFjv/FdM9fqdqwkP/YUnx5epvvHh/+/cQWjXTBbMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgP4MB0GA1UdDgQWBBR4YF2UOnLWDhOPLLuXYZum7xLMajAfBgNVHSMEGDAWgBRZXCF2vVvvaakHecbUVh7jS1yIVTANBgkqhkiG9w0BAQsFAAOCAQEAjBuZK2TcDhib12DSW8rW3kyjfQ3iYtjNSVd7vJ5jyI+0OYQ/NlhN4vVJx7Z02vnrBxv1Nh9swgT5Jpw0724KawGC4P+/bUEvKVz89tPMl9DaV98yQ2YN4cBfhcW3FpAoI4dzBbCzfEplsh9Ek7VxuIgwPozl0AdqOmTjZ3hh54ApSq/PMwENDyCEzD6bvrCrqCjgWSYIQUIvQ7LfO2HAlEE9DcoV4mSl/8uiQ05hRdGmNYUHZVUua0HHX1h/nAS+IcS6/EDd89kEGrL3M92a5wqnIQvDLO2NBCXhHSxoPVyBzv0lIgaO0ixD+q5P2OszRBYG3uk9W/uNIHdoyQn19w",
>
>
> "MIIDZjCCAk6gAwIBAgICAMgwDQYJKoZIhvcNAQELBQAwRDETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEVMBMGA1UEAxMMRGVtbyBSb290IENBMB4XDTA1MDcxMDEwMDAwMFoXDTI1MDcxMDA5NTk1OVowQzETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBndlYnBraTEUMBIGA1UEAxMLRGVtbyBTdWIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQI1w6lq0AsHbWMes8i/UGBeVQnlbzL2N8VyLjkbT3HXNHPUTjWWQElhoRzFA2xPaH++V/ecgr2Dkievrm+B5yIsdAL4oWWmgZ9KVMSfOrl5jy843p6AA55CHlP4j8v1uU1SpexIMUegDcNPlBwSRc0PPX+uqQ1STRg0kUgi4Bap7U5IRxTvp06adFXU4Bjr85ML7VZ3j+164t6mLnwF5RChJMlO7aVuz6TwxnWqeZytjFOei742dgbX9SHPVvytLtbFp4V/VFoEhaOXLZiOudPvpVwVdlfgE0AtiGHEWrfA74BU5XhME6UXzjcl3y3Ic304YGymo2jvmOwBki5wb3AgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRZXCF2vVvvaakHecbUVh7jS1yIVTAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAMlPdBaZ/+AMDfFYI9SLQenx0/vludp0oN9BSDe+mTfYNp5nS131cZRCKMAR3g/zzgkULu022xTJVsXfM1dsMYwEpGZp+GAvrlmRO6IathHW4aeo0QpaygOgfquQNYgS3Z8OJRSUDGnoY65g50dgv
>
> l1+ASbZX/r0/fNANLzXt/cnf0VXPrWdqvhuUSO561TsbTYg4qzcyDRV5vpjoUAxjFna06TJkeZR/OYMMcTtPRJON3/bMvzp7MFoL20PRPxu8nnqxwLWNzoQCkExS2yWHq1YDNNL4C/PIuyC/2IUbbPuwNp8ir3MVDBq4QwuXbw6xFvbPsxOmZyH10xvpsnmokg",
>
>
> "MIIDZjCCAk6gAwIBAgIBATANBgkqhkiG9w0BAQsFADBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwHhcNMDIwNzEwMTAwMDAwWhcNMzAwNzEwMDk1OTU5WjBEMRMwEQYKCZImiZPyLGQBGRYDb3JnMRYwFAYKCZImiZPyLGQBGRYGd2VicGtpMRUwEwYDVQQDEwxEZW1vIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCMR4ROlJJyBUzQ92XDSzFuxiMjwFqsrKXuIksIXMypjg2QZF4PzyQ0pu32/LVKuoaqbT+bkRKFdpUvMKhzGQ3rMAthTUkhXpFJN5Bk2LTcGXoE0B9wPKn4C3cxbUMEtT94m8PKIjRoKm77Rvdd4vrG1GiCw98WriMtNbX/psYzr/RikIcpEUpm4PPXzPPFuBzYIeDFG50aPEJu6arup5b1w7SQe6lq/f/XhKYWENH1LcQOFsMoQ8oUS/WsYQ8aeT6/FxjMumjv4f9LanUHb73bBPA0xiqtEfNIuK1ZogXgqT0157tqbmg2+GCSz+dGZv3VbSyQPdqh5s8YEGEK873vAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRaQnES9aDCSV/XOklJczxnqxI4/DAfBgNVHSMEGDAWgBRaQnES9aDCSV/XOklJczxnqxI4/DANBgkqhkiG9w0BAQsFAAOCAQEAHyxu0Z74ZYbWdy/fUtI9uIid/7F5AjbDdTzJcZgbSvyF3ZYVF62pRjSyxtIcCKbbr/oRPf5voYzlIP2UL7HGBB1WzKDnfP5sXWWEC5kYmo7NrYxTzbg22mS7nUpiro07qr1FTM1aCaJhu1RqioUK
>
> X4omlilZqTkTq6lBmDOdN+5RyBoA28EV+stt3+NV1JzOxIFqEqJfMW1q4Bzg5RM/S4xy/jCj/hMSn2Etm5YoNVwju2L86JZ8433SoemQWjl7qMHEJ1tTMEG9hR5DiE9j6STtbza+WbJHGqSdY/z1IsYbNgoZgYtJbRtZ4aObZb4FxflMTvObXiOInYgeKdK+Dw"
> ]
> }
> },
> "SignatureValue":
> "MEUCIQDWtK6Whx1aOrOYZ49OYiCcH/SqgyajLRbjh3GEdr6ItAIgFUuUbf9neRqWjLv99t/WceEkRBFZkRxaVz2/GBLzaOw"
> },
> "Additional": "Not signed since it comes after the
> EnvelopedSignature"
> }
> }
>
> Cheers
> Anders
> >
> >
> > On Wed, Aug 28, 2013 at 3:13 PM, jose issue tracker
> <[email protected]<mailto:trac%[email protected]>
> <mailto:trac%[email protected]<mailto:trac%[email protected]>>
>
> <mailto:[email protected]<mailto:trac%[email protected]>
> <mailto:trac%[email protected]<mailto:trac%[email protected]>>>>
> wrote:
> >
> > #59: Allow direct signing and align with AAD
> >
> >
> > Comment (by
> [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>):
> >
> > This largely seems to be an attempt to reopen issues #23 (Make
> crypto
> > independent of binary encoding (base64)) and #26 (Allow for
> signature
> > payload to not be base64 encoded), both of which were already
> closed as
> > "wontfix". In particular, both of the already-closed issues
> proposed
> > using an unencoded payload value as the signature input, rather
> than the
> > encoded value, which is the same as what is is being requested
> here.
> >
> > I therefore believe that this should be closed as a duplicate of
> #26.
> >
> > --
> >
> -------------------------+-------------------------------------------------
> > Reporter: [email protected]<mailto:[email protected]> | Owner:
> draft-ietf-jose-json-web-
> > Type: defect |
> [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
> > Priority: major | Status: new
> > Component: json-web- | Milestone:
> > signature | Version:
> > Severity: - | Resolution:
> > Keywords: |
> >
> -------------------------+-------------------------------------------------
> >
> > Ticket URL: <http://tools.ietf.org/wg/jose/trac/ticket/59#comment:2>
> > jose <http://tools.ietf.org/jose/>
> >
> > _______________________________________________
> > jose mailing list
> > [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
> > https://www.ietf.org/mailman/listinfo/jose
> >
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> > https://www.ietf.org/mailman/listinfo/jose
> >
>
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
