- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 04 Aug 2013 18:34:43 -0400
- To: "public-webid@w3.org" <public-webid@w3.org>
- CC: "foaf-protocols@lists.foaf-project.org" <foaf-protocols@lists.foaf-project.org>
- Message-ID: <51FED703.5000508@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Sunday, 4 August 2013 22:35:08 UTC