- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 05 Aug 2013 11:10:14 -0400
- To: public-webid@w3.org
- CC: "foaf-protocols@lists.foaf-project.org" <foaf-protocols@lists.foaf-project.org>
- Message-ID: <51FFC056.1000501@openlinksw.com>
On 8/5/13 10:33 AM, Peter Williams wrote: > reputation should be bound to persons (via their identifiers); not keys. Yes!!! > Keys (and security services such as signatures from keys) exist as > assurance evidence, only. By analogy, the local names assigned to > anonymous graph modes on processing the XML bearing the RDF graph > don't get used as public references... > While one can (and spies do) perform behavioral analysis of such > transient security metadata to build out inferences about membership > of the cryptonet in order to attack and penetrate the clique, in open > systems design one traditionally does NOT interfere with that. Its out > of scope, in some sense. Of course, the standards have to be written > such that one can “add” the military profile (for which the above is > IN scope). Cost effective military “COTS” procurements can then be > based on off the stuff we all use, with a win/win all around since the > military “upgrade” requires a decent baseline (in windows/Microsoft > and java/Oracle). > One saw this clearly in the X.500 world, in which public standards got > profiled as F.500 standards for phone companies trying to run public > identity servers, and profiles by NATO for military profiles wanting > to run a joint multi-national campaign requiring identifies from > disparate authorities to federate. In the latter, the profile might > put the tuned up access protocol and its information (aka identity) > model into an “application context” of multiple protocols, > furthermore, cooperating to augment the assurances ... or “protect” > the transient metadata associated with protocol runs from cryptonet > analysis. > For a while it was actually illegal to hide such transient metadata > (without an export license). Yep! > One thinks of the SSL handshake within a handshake, used originally to > enforce US export controls limiting strong[er] SSL ciphersuites to a > limited/vetted set of financial institutions. This hid the delivery of > an inner security service (that acted to turn off software crypto > limits built-into American OS products). It protected the US export > service’s cryptonet (the list of banks it was in a deals with) > This kind of design hygiene seems to keep the peace AND keep us moving > forward with delivering “useful” strong crypto. Yep! URI Everything and Everything is Cool! It's the URI that makes the Web what it is. That's the magic that's enabled data-de-silofication at massive scales, while also enabling us totally re-imagine the concept of structured data representation that's endowed with varying degrees of human- and machine-comprehensible entity relationship semantics. As long as uninvited 3rd parties are incapable of invading our minds we will have control over our privacy, if we choose :-) Kingsley > Sent from Windows Mail > *From:* Kingsley Idehen > *Sent:* Sunday, August 4, 2013 3:35 PM > *To:* public-webid@w3.org > *Cc:* foaf-protocols@lists.foaf-project.org > On 8/4/13 6:26 PM, Melvin Carvalho wrote: > > > > > On 5 August 2013 00:10, Kingsley Idehen <kidehen@openlinksw.com > <mailto:kidehen@openlinksw.com>> wrote: > > On 8/4/13 5:34 PM, Melvin Carvalho wrote: > > > > > On 4 August 2013 22:54, Peter Williams <home_pw@msn.com > <mailto:home_pw@msn.com>> wrote: > > one of the things that came “before its time” is > making a come back. One has to play the “factoring” > game “sensibly” - much as one has to allow security > committees to be stacked with agendized-folks with > money (that pays for core research, too). > If you look in dotNet, there is a particular > ws-trust/ws-security binding. Its compatible with > java, etc (circa 5 years ago, when Java security > mattered.) More importantly, its compatible with > apache libs, these days. In short, the saml process of > delivering a per-recipient encrypted proof key (within > the signed XML) was leveraged so that it delivered a > client’s EPHEMERAL rsa key. Any client proxy (and you > can have n of those, and being generated for a given > service instance exposing service&policy-metadata) can > maintain 1000 of these in its RSA security token > cache; before keys overwrite cache slots. Typically, > the client signs web service call headers (timestamp, > and address) using the RSA key, rather than signing > with hmac similarly. > So, if you are worried about your 512 bit RSA being > factored in 500 hours, (or 50, or 5) why not give it > a life time of 500mS, and just use 1000 of them? There > is built in probability drive in every CPU... > > > Ephemeral keys are a nice option. But long lived keys also > have advantages: > > 1. You can build up a reputation for each key > > > You can't have it both ways! > > > Sure it's a trade off. But of course reputation should be > transferable from one identity or key to another eg via signing ... > > > Yes, of course. It doesn't require a single key. It just requires a > Web- and Internet-scale verifiable identifier that denotes Agents. > Your reputation is scoped to your name, ultimately :-) > > > Note: > > 1. > http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fabout%2Fid%2Fentity%2Fhttp%2Ftwitter.com%2Fkidehen%23certF0549410169C0513116A03078AF5C59A992BBE57 > -- Certificate (its also a signed claim example since you can lookup > the signature too). > > 2. > http://id.myopenlink.net/describe/?url=http%3A%2F%2Fid.myopenlink.net%2Fcertgen%2Fkey%2F8954 > -- Public Key (which is paired with a Private Key) > > 3. http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen > -- WebID . > > Kingsley > > > > > 2. You can build cachable relationships between your > identity and your key > > > See comment above. > > > 3. You can store virtual currency against a key, and > transfer or prove ownership by signing > > > See comment above. > > 4. You can spend time generating a key via proof of work > algorithm to show you're not a sock puppet > > > See comment above. > > > So there's a trade off between security and key management. > > > > The moment you think about a single key, you've stopped > thinking about a composite key. Once you stop thinking about a > composite key, forget the entire pursuit. > > Remember, eons ago, I said this whole thing was about a > composite key + logic. Modulo Peter, I got a lot of strange > looks, and so I just stopped talking about composite keys, > mirrored claims, and a semantically driven web of trust. > > We can't have it both ways. The game has to be "deceptively > simple" but never "simply simple". > > Convenience is always the enemy of solid pursuits of complex > issues such as privacy. > > To conclude, "one key" doesn't work. A composite key has to be > the starting point. In WebID based trust thinking you have a > composite comprised of: > > 1. private key > 2. public key > 3. HTTP URI . > > Unlike a SQL DBMS composite key, this one is enhanced by the > fact that HTTP URIs are denoting Agents which introduces DNS > which introduces the Authority to persist claims. Then, again > unlike a SQL RDBMS we have logic discernible from the Trust > Web that starts with the Profile Graph and its > machine-comprehensible entity relationship semantics. Finally, > we have the keypair proof from asymmetric keys (the public and > private key pair) . > > When I construct a data access policy around your WebID it > isn't around a single key. It's actually around a composite > key re. the WebID+TLS protocol. In short, that would be the > case whenever the mirroring of claims between a locally stored > certificate and some publicly accessible profile document > drives the authentication protocol. > > There isn't a single secret. There isn't a single key. But > none of that stops the use of a WebID as a canonical > identifier for an Agent in a manner that scales to the Web and > the Internet. > > Kingsley > > > *From:* Melvin Carvalho > *Sent:* Sunday, August 4, 2013 10:14 AM > *To:* Peter Williams > *Cc:* public-webid, > foaf-protocols@lists.foaf-project.org > <mailto:foaf-protocols@lists.foaf-project.org> > > > > On 4 August 2013 17:16, Peter Williams > <home_pw@msn.com <mailto:home_pw@msn.com>> wrote: > > nothing new. > so use compression that is BUILT IN to the SSL > process. IT is properly tuned. It properly uses > the record layer so record-layer AND security > handshake boundaries are “application aware”. It > does make SSL more of an internet (i.e. layer 4 > peer entity layer) concept, than a webby layer > 7 “hypermedia concept”, though. > But, note that compression and SSL *was* patented > (and continuations may still be). It was > proactively-patented for national security > reasons; both good and bad. The good one was to > stop folks doing it completely wrong (this was at > a time when VeriSign required SSL vendors to > undergo a basic software audit to be allowed to > embed root keys, a governance technique designed > to “stop folks being stupid about basic comsec > that would undermine the value of the [VISA] brand > attached to certs”). The bad one was the usual CI > caveat reason - minimize the distribution of > knowhow about military cryptananalysis methods. We > are all still thinking 1980s, even in 1994, one > should recall. > A webid IDP is perfectly proper place to apply > better knowhow, as is ws-trust STS IDP that > leverages clients certs at layer 4 to authorize > SAML/JWT token minting. These are proper places to > apply strong crypto knowhow, speaking in terms of > social politics. > Sent from Windows Mail > > > Here's a great presentation about cracking RSA. > Perhaps we will need bigger keys or to switch to ECC > sooner than we thought ... > > http://www.slideshare.net/astamos/bh-slides > > *From:* Melvin Carvalho > *Sent:* Sunday, August 4, 2013 7:10 AM > *To:* public-webid, > foaf-protocols@lists.foaf-project.org > <mailto:foaf-protocols@lists.foaf-project.org> > http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ > > > > > > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org <mailto:foaf-protocols@lists.foaf-project.org> > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen> > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 5 August 2013 15:10:42 UTC