[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: XDI signatures
Inline.
I vote that the TC establish a virtual jar where everybody who is caught still using the old symbols has to contribute 0.01 BTC. That amount is doubled if you write a statement that mixes both the old and the new symbols.
once the web-based validator for XDI2 rejects the old notation, my brain may catch up. and, FWIW, i refuse to condone the use of bitcoin, so we would need a currency exchange :-P
See inline for comments.
On Wed, Apr 2, 2014 at 5:59 AM, =Drummond Reed <drummond@respectnetwork.net> wrote:
On Tue, Apr 1, 2014 at 3:49 PM, Davis, Peter <Peter.Davis@neustar.biz> wrote:
As i continue to refine the XDI Signature spec, I came to a realization that if we want to represent signatures in sub graphs, it may not always be possible to ensure an implementation can reliably reproduce a canonical form of the JSON-Flat serialization, and separately that it may not always be possible to move from one serialization (say, JSON tree) to JSON Flat. further, it may preclude the ability to have both signed sub graphs and a message signature at the same time (though i am not certain about that).
I don't think the signature spec should have any special rules for "messages", since they are just subgraphs like any other.
I was suggesting that there are applications when you do not want the signatures stored in the graph at all. if we store every message (with signatures), i would think the graph would grow enormous pretty quickly.
I don't understand why we don't specify—for the purpose of signatures—one canonical serialization format (such as JSON Flat) and just have everything that must produce signatures use that format? It should always be possible to represent any XDI graph in JSON flat serialization (or any of our serialization formats—they are all lossless and reproduce 100% of the graph).
you needed to read the following paragraph too… we DO presently define JSON Flat as the sole serialization format for signing today. what i am worried about is complexity for implementations (to get it right).
I agree.. Peter can you give an example of a graph that you think cannot move from one serialization to another?
I have not produced such a circumstance (yet), but i am concerned that we have not sufficiently proven it cannot happen (perhaps others have). looking at the more basic issue of code complexity:
serializes as:{"=markus<#email>&/&": "markus.sabadello@gmail.com","=markus/#friend": ["=peterd","=drummond"]}
the canonicalization rules would therefore require that not only are the JSON ‘keys’ be sorted:"=markus/#friend”"=markus<#email>&/&”
the values of "=markus/#friend” must also be sorted:"=drummond","=peterd"
resulting in:{"=markus/#friend": ["=drummond","=peterd"],"=markus<#email>&/&": "markus.sabadello@gmail.com"}
so while this is not an issue for such trivial examples, it may prove problematic for very large graphs that require canonicalization, and is prone to errors (and thus signature validation errors). Moving to a JOSE-style signature eliminates entirely the notion of a canonical form in JSON.
The present proposal requires JSON Flat as the only serialization for signing, and that the signature information is “added” to the graph (i.e. the encrypted hash).
I am thinking about a new approach that mimics JOSE signatures, and completely eliminates the complexities of defining canonicalization rules. working on examples now.
Ok. Very curious to see how that will work.
I should have some examples later today/tomorrow...
separately, i wanted to validate some of the graph examples i plan on using in the specs (note that the sig metadata may not be complete, but you get the idea):
in response to a $get for ="" friends, one might see the following, where drummond and peterd were the signers:
/* drummond sig on the friend arc) */=markus/+friend/=drummond(=markus=drummond/+friend)<$sig>/$is#/$sha$256$rsa(=markus=drummond/+friend)<$sig><$key><$url>/$is#/$pem(=markus=drummond/+friend)<$sig><$key><$url>&/&/"https://example.biz/=drummond.pem"(=markus=drummond/+friend)<$sig><$notAfter>&/&/"2012-01-01T00:00:00Z"(=markus=drummond/+friend)<$sig>&/&/"lascj9scoamc..."
So if the graph statement is
=markus/+friend/=drummond
Then a signature on the arc would have to use the inner graph:
(=markus/+friend)=drummond
That would replace the string "(=markus=drummond/+friend)" in all your lines above (and similarly for below).
OK. that makes sense. I got the inner graph notation from animesh, so perhaps there is some confusion on inner graph notations?The goal is to have a notation in markus’ graph that states: “the identified node (sub graph) is signed. please find that signature in drummond’s graph ‘here’”. this has a few advantages, including not having stale public keys in foreign graphs. perhaps i have an incorrect understanding of how $ref is used.
Yes, if we have a relation such as the following:
[=]!:uuid:3333/#guardian/[=]!:uuid:1111
Then strictly speaking we cannot put a signature on the arc itself, but we can approximate this functionality with an inner root pattern, such as the one you have above.
In the RN Member Graph, we are currently modeling signatures on guardian statements as follows:
[=]!:uuid:3333/#guardian/[=]!:uuid:1111([=]!:uuid:3333/#guardian)[=]!:uuid:3333/#guardian/([=]!:uuid:3333/#guardian)[=]!:uuid:1111
([=]!:uuid:3333/#guardian)[<$sig>]<!:uuid:7846>&/&/”...”([=]!:uuid:3333/#guardian)[<$sig>]<!:uuid:7846>/$is#/([=]!:uuid:3333/#guardian)$sha$256$rsa$2048([=]!:uuid:3333/#guardian)[<$sig>]<!:uuid:7846><$public><$key>/$ref/([=]!:uuid:3333/#guardian)[=]!:uuid:1111$sig$keypair<$public><$key>
/* peterd sig on the friend arc) */=markus/+friend/=peterd(=markus=peterd/+friend)<$sig>/$is#/$sha$256$rsa(=markus= peterd/+friend)<$sig><$key><$url>/$is#/$pem(=markus= peterd/+friend)<$sig><$key><$url>&/&/"https://example.biz/=peterd.pem"(=markus= peterd/+friend)<$sig><$notAfter>&/&/"2012-01-01T00:00:00Z"(=markus= peterd/+friend)<$sig>&/&/“jhsjudf83ifw…"
the next one i am struggling with.. essentially detached signatures, i want the markus graph to point to a signature in drummonds graph, which i think is:
=markus/+friend/=drummond(=markus=drummond/+friend)<$sig>/$ref/((=drummond=markus/+friend)<$sig>)
I think what you want is:
(=markus/+friend)=drummond<$sig>/$ref/(=drummond/+friend)=markus/<$sig>
I'm not sure that's right because essentially you're saying that Drummond's signature is the same as Markus's, which sounds logically strange.In addition, there might be a problem with the $ref crossing between inner graphs, which is something we've been discussing. I think it's okay for equivalence relations ($is, $ref, $rep) to do that, but we need to check with Markus.
Hmm yes I can see how this would be allowed for cases like this.
Currently, we don't have arcs crossing between inner graphs anywhere.
The XDI2 implementation does allow it, i.e. it won't complain if you create such arcs.
Of course then the inner root "short notations" can't be used, but that's okay.
=Drummond
=peterd
Distinguished Engineer, Director, Neustar FoundryPeter Davis: Neustar, Inc.45980 Center Oak Plaza Sterling, VA 20166[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterdThe information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]