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