Hi Anders
That resembles a bit a JWS JSON serialization format; if a signature is
taken on a thumbprint of the natural payload, then perhaps there's some
scope for the alignment there ?
Let me clarify what I meant.
If we look at a complete serialization example,
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-38#appendix-A.6.4,
one can imagine this representation having not a "payload" property
representing an encoded payload but whatever the custom document would
have, but the signatures/header would qualify that a signatures are
calculated over a thumbprint:
{
"a": "b",
"c": "d",
"signatures":[
{"protected":"eyJhbGciOiJSUzI1NiJ9",
"header":
{"kid":"2010-12-29", "signatureType":"thumbprint"},
"signature": "..."}
]
}
The consumer would calculate a thumbprint of the JSON payload minus
"signatures", possibly of "signatures" siblings only to support signing
of individual doc parts, and verify...
Not sure it makes much sense, just clarifying what I thought when I saw
your example :-)
Well, the alignment is that JCS is nimble and can use JOSE algorithms.
What does "JCS is nimble" mean ? Sorry for being ignorant :-)
Unfortunately it stops there as I don't think that the following
dual-signed message
(card-holder signs a signed payment request + other data) would fit
nicely in JWS:
{
"@context": "http://xmlns.webpki.org/wcpp-payment-demo";,
"@qualifier": "AuthData",
"paymentRequest":
{
"commonName": "Demo Merchant",
"amount": 8600550,
"currency": "USD",
"referenceId": "#1000001",
"dateTime": "2014-12-10T13:33:16Z",
"signature":
{
"algorithm": "RS256",
"signerCertificate":
{
"issuer": "CN=Merchant Network Sub CA5,C=DE",
"serialNumber": "1413983542582",
"subject": "CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE"
},
"certificatePath":
[
"MIIDQzCCAiugAwIBAgIGAUk3_J02MA0GCS...MMGP3eMGlY734U3hxrdDbphEvsWTc",
"MIIEPzCCAiegAwIBAgIBBTANBgkqhkiG9w...IyRGA7IbdHOeDB2RUpsXloU2QKfLrk"
],
"value":
"xVCFsxvB0y8j1GSi_rnXg4fcHQXDAv-...wNMhH8j4E99979WhDK5x9viUNvg"
}
},
"domainName": "localhost",
"cardType": "SuperCard",
"pan": "7222464316037372",
"dateTime": "2014-12-10T13:33:22Z",
"signature":
{
"algorithm": "RS256",
"signerCertificate":
{
"issuer": "CN=Mybank Client Root CA1,C=US",
"serialNumber": "1413983550045",
"subject": "CN=The Cardholder,2.5.4.5=#13083935363733353232"
},
"certificatePath":
[
"MIIENzCCAh-gAwIBAgIGAUk3_LpdMA0....eo5DndNnV8D0UM-oBRkUDDFiWlhCU"
],
"value":
"Ey1E0To7VDEXasNC5kiAr_bXrV...1uVfiQMs4ih7j4qegzOD7npk7wCFeOXs8VA"
}
}
Are you referring to the fact one can have various individual parts of
the same document signed with JCS ?
The JSON parser I use performs strict type-checking and automatically
detects
if there for example are "alien" properties in a signature container.
thanks, Sergey
cheers,
Anders
Sergey
On 10/12/14 07:18, Anders Rundgren wrote:
Dropping XML DSig bloat and adding support for JOSE algorithms made JCS
even nicer:
{
"Statement": "Hello signed world!",
"OtherProperties": [2000,true],
"signature":
{
"algorithm": "ES256",
"publicKey":
{
"type": "EC",
"curve": "P-256",
"x":
"vlYxD4dtFJOp1_8_QUcieWCW-4KrLMmFL2rpkY1bQDs",
"y": "fxEF70yJenP3SPHM9hv-EnvhG6nXr3_S-fDqoj-F6yM"
},
"value":
"MEUCIQDXU1ph6-MRs0upj5PHA_bOcUv0pz5zIpvcQowgVj_wzQIgRW1_VMuTtc7C64vMh2kKpdGC70tqjpAAcbnn2qnVGuE"
}
}
My claim that JSON parsers featured in browsers are compliant with JCS
was unfortunately not entirely correct -(
Properties expressed as numbers only ("1":"hi!"), are dealt with in a
special way. OTOH, this seems like an
unusual construct so it is not a show-stopper.
Cheers,
Anders
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
