- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 02 Sep 2013 17:08:05 +0200
- To: David Chadwick <d.w.chadwick@kent.ac.uk>
- CC: Anders Rundgren <anders.rundgren@telia.com>, "public-identity@w3.org" <public-identity@w3.org>
On 2013-09-02 12:43, David Chadwick wrote: > Hi Anders Hi David, > > given that JSC should be scaled down and simplified version of DSIG can > I suggest two simplifications > > i) only one path should be in certification path, and not multiple paths This is what I meant :-) Now I have upgraded the text a bit. > ii) the path should start with the root of trust and end with the > signer's certificate, as this is the order needed for path validation. > Currently you have it with the signer's certificate as the first cert in > the path. It seems that many APIs think differently and recent standards-in-progress have [probably] followed that: http://tools.ietf.org/id/draft-ietf-jose-json-web-signature-14.html#rfc.section.4.1.6 Regards, Anders > > FYI, the X.509 standard defines PKIPath to be precisely the above > > regards > > David > > > On 02/09/2013 10:18, Anders Rundgren wrote: >> On 2013-09-02 10:08, David Chadwick wrote: >>> Hi Anders >>> >>> I am interested in the contents of the "X509CertificatePath" element. >>> Which certificates does it contain in which order? Does it contain >>> multiple paths? Is it taken from any standard definition (such as the >>> OASIS J2ME Code-Signing Profile of the OASIS Digital Signature Services >>> Standard of 11 April 2007) >> >> Hi David, >> >> Thank you for pointing out this glaring hole in the documentation ! >> It has been fixed now (update 0.44): >> >> https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf >> >> I think JCS should be regarded as an _extremely_ scaled-down and simplified version of XML DSig. >> The primary target for JCS are security protocols with KeyGen2 as the first "victim". >> >> Regards >> Anders >> >> >>> >>> regards >>> >>> David >>> >>> >>> On 31/08/2013 04:22, Anders Rundgren wrote: >>>> Hi, >>>> Based on the _extremely_ useful feedback received, I have decided to update the proposed clear-text JSON Signature scheme. >>>> >>>> Canonicalization: >>>> - Remove whitespace >>>> - Unescape "strings" >>>> - Sort properties >>>> >>>> Signature scope: a JSON Signature signs the object (including possible child objects) it is declared in. >>>> >>>> That is, the final XML DSig "leftover", the awkward Reference has been shelved. >>>> I expect the resulting code to be even shorter than today :-) >>>> >>>> { >>>> "@context": "http://example.com/test-signature", >>>> "Now": "2013-08-30T07:56:08+02:00", >>>> "ID": "lADU_sO067Wlgoo52-9L", >>>> "STRINGS": ["One","Two","Three"], >>>> "EscapeMe": "A\\\n\"", >>>> "Intra": 78, >>>> "Signature": >>>> { >>>> "SignatureInfo": >>>> { >>>> "Algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256", >>>> "KeyInfo": >>>> { >>>> "SignatureCertificate": >>>> { >>>> "Issuer": "CN=Demo Sub CA,DC=webpki,DC=org", >>>> "SerialNumber": 1377713637130, >>>> "Subject": "CN=example.com,O=Example Organization,C=US" >>>> }, >>>> "X509CertificatePath": >>>> [ >>>> "MIIClzCCAX+gAwIBAgIG...RBYG3uk9W/uNIHdoyQn19w==" >>>> ] >>>> } >>>> }, >>>> "SignatureValue": "MEYCIQCCAxLBoPw5h8hW4M...L5t0XscOTPWXE67c1SCT" >>>> }, >>>> } >>>> >>>> The sample shows the new KeyGen2 message structure which has been derived from JSON-LD (@context) >>>> >>>> Cheers >>>> Anders >>>> >>
Received on Monday, 2 September 2013 15:08:39 UTC