- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Tue, 20 May 2014 19:35:12 +1000
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, "public-webid@w3.org" <public-webid@w3.org>
TLS cert via subjectAltName is a stroke of genius IMHO. I know a multitude of records can be added to a cert. Perhaps that's the least disruptive method for creating a v2... Sent from my iPad > On 20 May 2014, at 6:35 pm, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote: > > >> On 20 May 2014, at 09:37, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: >> >>> 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 your reasons against changing the TLS protocol are exactly the reasons > against inventing a new protocol. So it follows that the best choice is to > design around TLS as it is, in order to prove the use of LinkedData with > Authentication, which is what we are really interested in here. > > >> >> Anders >> >> >>> >>> >>>> >>>> M. >>>> >>>> -- >>>> Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space, >>>> Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA. > > Social Web Architect > http://bblfish.net/ > >
Received on Tuesday, 20 May 2014 09:35:51 UTC