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