Re: WebID, BrowserID and NSTIC

I've worked in govt - and know the pressure to (re)set the standard. This often involves adding features (and assurances).

Here, the mission is to leverage what exists (for nearly 20 years); fits properly with the web (which is more than a line protocol); and exploit what already exists in a few billion devices (including the last 5 years versions).

Unusually, it's not a forum full of designers of security protocols.

This any argument of the form: argue for x' by compare and contrast with older x doesn't hold, as older x is desired (being commodity).

This is why we are stuck with ssl client certs and browser keygen/object-tag (in general). Yes the largest deployment of ssl is dod's cac card (not using keygen), and yes we know IRS effectiveness is limited (to intranet/sslvpn/smime vs web) interactions.

But tweaking all "that"  is what we are all about - here. 

We are not trying to be the usual ietf/NSA/did/cseg sponsored forum. We are trying to add security to the semantic web (without losing the soul of the web).

Half the battle is educating the non security professionals here on just what the commodity security model includes, increasingly in the more subtle points of https (and it's melding with the web, semantic or otherwise).



On Jul 30, 2011, at 4:13 PM, Francisco Corella <fcorella@pomcor.com> wrote:

> > > > One difference is that, when you use <KEYGEN>, the browser that
> > > > requests the certificate does not demonstrate knowledge of the private
> > > > key, whereas in the proposed NSTIC architecture the certificate is
> > > > issued by executing an issuance protocol (within the proposed TLS
> > > > "server-initiated exchange") where the browser does have to
> > > > demonstrate knowledge of the private key.
> > http://old.nabble.com/The-%3Ckeygen%3E-element-td22921620.html
> 
> Oops!  I thought <KEYGEN> just sent the public key to the server.  I
> didn't realize it also sends a signature computed with the associated
> private key, which demonstrates knowledge of the private key.  So use
> of <KEYGEN> is equivalent to the issuance protocol in the proposed
> NSTIC architecture.
> 
> (For a issuing a credential such as an Idemix anonymous credential or
> a U-Prove token, the issuance protocol involves an exchange of several
> messages, so something like <KEYGEN> would not work.)
> 
> Francisco
>