W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

RE: TLS-Light

From: Peter Williams <home_pw@msn.com>
Date: Wed, 30 Nov 2011 07:08:21 -0800
Message-ID: <SNT143-W181DFADBE1C6882D71402292B00@phx.gbl>
To: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

given copies of the public key exist in a billion http caches, HOW in semantic web and linked data *culture* does "disablement" occur? It needs to say. I doubt this sepc will be read by mom and pop users. It's far too technical. Im not sure a vendor would know what to do or to measure, either.


Theft of a .p12 file export of a browser (*or platform) credential store typically copies the private key within (since most PC security systems use software crypto). Once its stolen, like most IP its hard to get all the copies back. Getting assurance you have all the copies is essentially impossible, for the costs folks will typically bear. Its irrelevant whether its password protected (and that the password is a secret from which a data encryption key is drived, used in an AES encipherment mechianism within .p12).Compromise means "loss of control" and inability to assign risk metrics.


Compromise recovery (vs revocation of crredentials for access controls" in key management is basically what distinguish a Lexus from a Ford. Key distribution is what a webid profile does, sitting on some blog site firing packets out



be careful when saying vacous things such as :"citizens of the world are responsible for the future of the human race, and when noticing that others are not eating well, users need to take action to make distribution of the the food supply more fair." Its tempting to be use idealisms, to cover up lack of professional engineering.In many corporate use cases, Bob will not be responsible in the manner suggested, and BOB will NOT be the party doing the compromise recovery (Bob will run away, or be fired, typically). Decide  if corporate culture IS or IS NOT a part of the community of users anticipated by webid in the next 3 years. Be clear in terminology, and tone. Appeal to an audience (other than 10 developers of code).

"+<dd>Bob is an agent who uses a <tref>Client</tref> to connect to <tref>Alice</tref>'s Service, and who is responsible for the private key the <tref>Client</tref> uses to authenticate to <tref>Service</tref>s.
    3.23 +If he notices the private key was compromised he needs to take action to disable the public key."


I notice that the spec draft can no longer be tagged as being anti-CA, since it defines a CA for the first time.


Its focus on TLS rather than https (the protocol identified by the scheme) is unfortunate. https is not the same as TLS, as https uses SSL sessions in a particular way for hypermedia. Web services over HTTP typically use TLS without conforming to the https scheme used in mozilla-class clients.


> From: henry.story@bblfish.net
> Date: Wed, 30 Nov 2011 14:58:02 +0100
> To: public-xg-webid@w3.org
> Subject: TLS-Light
> I have updated the spec with the notion of TLS-Light . See the new spec in mercurial and the following diff
> https://dvcs.w3.org/hg/WebID/rev/3012b63e69f3
> The idea is to clarify that the TLS service we use is a simplified TLS service: therefore than any existing TLS service should be useable: i.e. no big backend infrastructure changes needed.
> Henry
> Social Web Architect
> http://bblfish.net/
Received on Wednesday, 30 November 2011 15:08:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:48 UTC