Re: FYI: proposal for client authentication in TLS

On 10 Mar 2014, at 13:56, Tim Holborn <timothy.holborn@gmail.com> wrote:

> oh - typo on front page: 
> 
> http://www.w3.org/2005/Incubator/webid/spec/
> 
> it should allow flexbile access control that is both easy for humans and machines to use and understand,
> 
> vs.
> it should allow flexible access control that is both easy for humans and machines to use and understand,
fixed in Mercurial. I also found a mistake in the TLS spec which I also pushed to Mercurial.
Both of these are small enough that they could be fixed directly in CVS too. 

As it happens CVS version at http://www.w3.org/2005/Incubator/webid/spec/
should have a pointer to the mercurial developers draft, and the same with the other two specs
where that pointer is no longer correct.

Henry

> 
> On 10 Mar 2014, at 11:37 pm, Tim Holborn <timothy.holborn@gmail.com> wrote:
> 
>> yes; perhaps confusing.
>> 
>> i understand use of ‘actor' is a foaf issue.
>> 
>> Below you state agent = Agent ( human, robot, organisation, …) - therein a mixture between legal entities and machines / services / service entry points perhaps also (etc.)
>> 
>> The term agent has a very broad application.  actor might best mean legal entity or FOAF:Person?  Therein, does person mean legal entity (i.e. natural or incorporated entity?) and agent mean something authorised by legal entity… 
>> 
>> Vint talks alot about his wine sensors; i think also, protecting his wine sensor network from hackers, etc.  I imagine he could issue his sensor controller a WebID; which could then be linked to whatever his using as a conductor (like an orchestra) to secure his sensor info… 
>> 
>> Whether that’s done directly or indirectly; the sensor controller in that example would be an agent. 
>> 
>> or; organisation is historical society (person? - incorporated legal entity); they have a heritage library (agent) that is capable of issuing ACL’s (i.e. public metadata contributions) via WebID Auth rules (Geographic, Community, etc) to other agents (i.e. a national heritage aggregation site, or an interactive educational environment served off a server somewhere) or a person (family member doing genealogical research for example)…
>> 
>> found https://www.youtube.com/watch?v=ZYAJaOVuyxI too
>> 
>> timh
>> 
>> On 10 Mar 2014, at 11:12 pm, henry.story@bblfish.net wrote:
>> 
>>> 
>>> On 10 Mar 2014, at 10:35, Timothy Holborn <timothy.holborn@gmail.com> wrote:
>>> 
>>>> Agent = a certified or authorised actor of a legal entity?  
>>> 
>>> An Agent is what you mean by an Actor. We could have used actor, but we have widely used the term agent.
>>> 
>>>> 
>>>> A machine or account is not a legal entity; vs. a natural or incorporated legal entity.  Therein, a legal entity provides a machine the authority to do something on it's behalf....
>>>> 
>>>> Ie:  I authorise my rww data space to share specific protected resources / data, to others (inc other agents) on my behalf without human intervention on an event basis?
>>>> 
>>>> A bit WAC (or alternative) but hope u see the webID/foaf/IoT (Internet of things / web of things) concept therein...
>>> 
>>> yes, you could have a WebID for a machine, or service. 
>>> 
>>>> 
>>>> Timh.
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>> On 10 Mar 2014, at 8:23 pm, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
>>>>> 
>>>>> The draft-thomson-tls-care comes with a draft-thomson-httpbis-catch. 
>>>>> I wrote to the https-bis mailing list with the following suggestion.
>>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>>> From: "henry.story@bblfish.net" <henry.story@bblfish.net>
>>>>>> Subject: Re: FYI: proposal for client authentication in TLS
>>>>>> Date: 10 March 2014 10:16:01 CET
>>>>>> To: Martin Thomson <martin.thomson@gmail.com>
>>>>>> Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
>>>>>> 
>>>>>> 
>>>>>>> On 9 Mar 2014, at 08:37, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>>>>> 
>>>>>>>> On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote:
>>>>>>>> Pursuant to our discussion on TLS renegotiation, I've submitted part 1
>>>>>>>> of the solution I proposed as an internet draft.
>>>>>>>> 
>>>>>>>> http://datatracker.ietf.org/doc/draft-thomson-tls-care/
>>>>>>>> 
>>>>>>>> If we agree to a mechanism whereby we augment the 401 status code with
>>>>>>>> a "go away and make a new TLS connection with client authentication",
>>>>>>>> then this is necessary, so that the server knows to request a client
>>>>>>>> certificate.
>>>>>>> 
>>>>>>> Now with part 2:
>>>>>>> 
>>>>>>> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/
>>>>>> 
>>>>>> I really like both of these.  I allready responded on the TLS mailing list
>>>>>> about draft-thomson-tls-care [1]. For draft-thomson-httbis-catch I would
>>>>>> like to suggest an improvement that would be essential for "self-signed"
>>>>>> or rather "unknown server signed" certificates, i.e., certificates signed
>>>>>> by some server that is not a CA. This allows for much more widespread
>>>>>> creation of client certificates, since they don't anymore need to be
>>>>>> verified by a few CAs, but instead allows the deployment of a web of
>>>>>> trust - a linked data web of trust to be precise. This allows one client
>>>>>> side certificate to be used to sign on to any web site.
>>>>>> 
>>>>>> A WebID is just an http(s) URL that refers to an Agent ( human, robot, 
>>>>>> organisation, ...) We have defined it in the spec "WebID 1.0" [2]. One
>>>>>> can then place a WebID in the Subject Alternative Name (SAN) field of an X509 
>>>>>> certificate as shown  in WebID Authentication over TLS [3] ( or even in the 
>>>>>> Issuer Alternative Name field (IAN)). The last spec relies on TLS as it is
>>>>>> currently, but would be redundant if draft-thomson-httpbis-catch went through.
>>>>>> (Until wide deployment of TLS1.3 which I suppose may take some time). 
>>>>>> 
>>>>>> Now I am not absolutely sure where this improvement I want to suggest, 
>>>>>> needs to be added: at the HTTP layer, or at the TLS layer. Currently TLS
>>>>>> allows a server to specify using the certificate_authorities list what
>>>>>> the list of Certificate Authorities the server accepts, so that the client
>>>>>> does not send Certificates that are not signed by one that is known to the server,
>>>>>> and which the server would then have to refuse.
>>>>>> But with WebID Authentication we don't need a CA, so it would be nice to be
>>>>>> able to specify that the server knows how to do WebID verification, ie part
>>>>>> 5 and 6 of 
>>>>>> http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence
>>>>>> bB
>>>>>> If in TLS the server sends the empty certificate_authorities list. But that
>>>>>> is too wide, since that means the client can send ANY Certificate. The
>>>>>> server may not know what to do with most of them ( other than perhaps
>>>>>> identify the user indirectly by the public key, but that is only minimally
>>>>>> interesting - it does not allow one to build a web of trust ). 
>>>>>> 
>>>>>> My guess is that since this could evolve faster than the TLS layer, it may
>>>>>> be better if this were done in the HTTP header. So perhaps a header like
>>>>>> 
>>>>>> WWW-Authenticate: ClientCertificate,SAN=WebID
>>>>>> 
>>>>>> would do. One could also imagine a 
>>>>>> 
>>>>>> WWW-Authenticate: ClientCertificate,IAN=WebID
>>>>>> 
>>>>>> so that services with a lot of WebIDs could allow people to verify certificates
>>>>>> by verifying the issuer. A client seeing this would know that if the
>>>>>> server sent the empty certificate_authorities list, that it could filter its
>>>>>> available certificates by those that have the SAN or IAN fields filled in.
>>>>>> 
>>>>>> We have quite a few implementations of WebID on numerous servers, and in
>>>>>> pretty much every language, and we are finding it very useful. To get
>>>>>> a full overview of how this ties into a bigger picture including Web Access
>>>>>> Control, other authentication schemes, Linked Data Protocol,  etc... see our main 
>>>>>> intro page
>>>>>> 
>>>>>> http://www.w3.org/2005/Incubator/webid/spec/
>>>>>> 
>>>>>> Hope this helps.
>>>>>> 
>>>>>> Henry
>>>>>> 
>>>>>> 
>>>>>> [1] http://www.ietf.org/mail-archive/web/tls/current/msg11449.html
>>>>>> [2] http://www.w3.org/2005/Incubator/webid/spec/identity/
>>>>>> [3] http://www.w3.org/2005/Incubator/webid/spec/tls/
>>>>>> 
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>> 
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>> 
>>>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Monday, 10 March 2014 13:21:13 UTC