Re: A WebID Implementation => HTTPS Client Certificate Authentication lacks a useful filter mechanism.

On 2014-05-20 06:03, henry.story@bblfish.net wrote:
> 
> On 20 May 2014, at 01:13, Mo McRoberts <mo.mcroberts@bbc.co.uk> wrote:
> 
>>
>> On  2014-May-19, at 23:05, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>>>> For WebID-X.509 a specific WebID policy OID would be ideal since it
>>>> doesn't interfere with anything else.
>>>
>>> And that would change what in regards to Browser behavior, in their current form?
>>
>> Browsers which implemented it would only prompt for selection of certificates containing the extension which the server said it wanted (similarly to how the list is filtered now if you request client certs from specific CAs, but without it being so horribly kludgy).
> 
> The only way I know of for server to signal something about certificate selection to the client is via the
> certificates_list message. This was explained in more detail in ISSUE-62, in this message for example:
> 
> http://lists.w3.org/Archives/Public/public-webid/2013Dec/0006.html
> 
> ( for some of the debate
>   http://www.w3.org/2005/Incubator/webid/track/issues/62 )
> 
> I still don't think we have really done enough testing to see if we can't really build
> something that cleverly uses this feature of TLS, and after specifying a WebID DN resolve this problem. 
> 
>>
>> Browsers which didn’t implement it would behave as they do now.
>>
>> It’s very sensible, and I’d love to see it happen — though I’m not about to hold my breath.
> 
> How would this OID be used in a request from the server to the client? Does that require a change
> in the TLS protocol? Do you think we could get by with the above mentioned proposal?

I believe that changing the TLS protocol is pretty unrealistic given
1) the time needed to roll out new TLS versions
2) the limited use of HTTPS Client Certificate Authentication through browsers
3) that it would also require changes in browsers and in things like the Servlet API
4) the quirky session workarounds which also are needed

There are AFAICT three possible alternatives:
- Continue with the "bag of tricks" to make HTTPS CCA sort of usable

- Design a WebID-U2F.  I don't see how that's is possible but
  other people claim that it is easy

- Create a brand new X.509 authentication solution that covers a
  wide range of applications including on-line banking which would
  work on the application-level rather than on the transport ditto
  (leaving TLS unchanged)

Personally I continue with the latter since almost all big users of
consumer-PKI have created their own PKI client and that's IMO not
very good for anybody.

Anders


> 
> 
>>
>> M.
>>
>> --
>> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
>> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA.
>>
>>
> 
>

Received on Tuesday, 20 May 2014 07:38:00 UTC