RE: WebID-ISSUE-15: Native browser-based WebID-only certificate display

dont forget SSL v1 and v2 was not defined by "security experts"  (tajar excepted). It was pretty average programmers, taking the best of a long and winding (and ever winding) thread of discussion on IPsec lists and doing something similar behind a socket - suiting https, nntps and other hypermedia type interactions (which was the novelty, in the driving requirement set). it didnt even have client certs, originally (it assumed https was going to be carefully aligned with http and webauth headers). It was really only the addition of DH ciphersuite that forced the handshake to evolve, to need client certs and then exploit the differing properties of the key management primitives in each class of handshake. NSA pushed both Netscape and Microsoft further, by making folks understand the fortezza variety of handshake (which basically put the first ephemeral component into the mix).
 
At the same time as SSL v2 was making its case, Alan/Eric's S-HTTP was out there setting the contrast point, with quite a different delivery concept (and broadly doing what eventually we do in the form of ws-trust - now powering the microsoft identity framework for SOAP, and power REST via its WRAP incarnation). I remember the meeting to this day when Schiffman (funded by DARPA at that point, as I recall) did what a public researcher does - outlining his slightly biased case for his proposal, without denying the alternative against which he contrasted each design point. One appeals to the audience, and one accepts their judgement. The audience in thse days was the great and good of the Menlo Park set, lynchpinned by DEC if I recall right.
 
Ive found key management design to be a distibuted process not a complicated process, having watched 10 of them (including more than one half-secret one).
 
None of this requires buyin to the "super secret" world, mystical subservience to super special, highly spooky james bond style defense contractors types, with secret, hidden knowledge spaces. What those folks do offer (and MUST) bring to this table (once they get the buzz) is the experience of how not to screw up (since they remember the last 30 screw ups). But, its little more than : just dont do THAT. here is some patterns that get you to at least 80% assurance, quick. To work with them, just listen and do SOME of it, where some gets bigger each trimester.
 
 
 

 
> From: henry.story@bblfish.net
> Date: Mon, 31 Jan 2011 19:30:42 +0100
> To: public-xg-webid@w3.org
> Subject: Re: WebID-ISSUE-15: Native browser-based WebID-only certificate display
> 
> This is the type of issue that is a real standardisation issue that will be
> complex to solve correctly, that will need security experts, and a wider
> discussion by interested parties to help find the right solution. With foaf+ssl
> it was not worth going into details to solve this other than theoretically.
> 
> Assuming the solution of giving WebID enabled X509 certificates a particular
> Issuer DN, so that servers can request certificates that are WebID enabled - 
> just settling on a correct name requires us to have a spec and a process 
> whereby such a decision can get the agreement of the widest number of
> participants.
> 
> Henry Story
> 
> 
> On 31 Jan 2011, at 17:54, Stéphane Corlosquet wrote:
> 
> > ---------- Forwarded message ----------
> > From: Henry Story <henry.story@bblfish.net>
> > Date: Tue, Sep 7, 2010 at 4:04 PM
> > Subject: [foaf-protocols] Selective presentation of WebID-only certificates
> > To: foaf-protocols@lists.foaf-project.org
> > 
> > 
> > Manu Sporny logged this issue here:
> > 
> > http://github.com/msporny/webid-spec/issues#issue/3
> > 
> > Bruno Harbulot brought this up in April 2009
> > 
> > http://lists.foaf-project.org/pipermail/foaf-protocols/2009-April/000450.html
> > 
> > It came up again a few times such as in this thread
> > 
> > http://foaf.markmail.org/thread/b2nfaspp3uqb5usz
> > 
> > The issues I think is
> > 
> > 1. to check what the browser behavior really is
> > 2. to make sure the semantics of doing this is ok (I think it is)
> > 3. what would the name of this Cert Authority be
> > Currently I have used the DN of
> > "O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority";
> > but we would need to agree on this.
> > 
> > I was thinking we should wait until we have a very formal process to decide on this, because we want as many people to be happy with it as possible - or else we would be in danger of not asking people with valid certificates for certificates, just because they decided to choose another DN.
> > 
> > So the issue is also in part to understand how bad the issue of multiple certs is. The advantage is that we could tie the DN to major spec version numbers, ....
> > 
> > Anyway this is a complex issue. It seems there is a solution to it, so it's just a matter of working out the details.
> > 
> > Henry
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> > On Mon, Jan 31, 2011 at 11:50 AM, WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org> wrote:
> > 
> > WebID-ISSUE-15: Native browser-based WebID-only certificate display
> > 
> > http://www.w3.org/2005/Incubator/webid/track/issues/15
> > 
> > Raised by: Stéphane Corlosquet
> > On product:
> > 
> > Issue raised by Manu Sporny at https://github.com/webid-community/webid-spec/issues#issue/3
> > 
> > When connecting to a WebID capable website, we need to understand how to display purely WebID-only certificates. This is an issue in corporate and university environments where client-side certificates are provided that could be selected when logging into WebID websites.
> > 
> > The usability concern is that people might select the wrong certificate when connecting with a service, or that they don't have a WebID certificate, but are given the certificate selection prompt anyway (which would be very confusing to someone that doesn't know about certificates).
> > 
> > We need to understand if there is a way to specify that only WebID certificates are requested on a WebID-capable website. If there is a way to do this, we need to settle on a naming convention or certificate authority name/chain that makes this possible.
> > 
> > 
> > 
> > 
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>