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 protected]]
Sent: Thursday, August 29, 2013 8:16 AM
To: Justin Richer
Cc: Anders Rundgren; Jim Schaad; Mike Jones; [email protected]
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 protected]<mailto:[email protected]>> 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 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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
