Re: WebID, BrowserID and NSTIC

Melvin,

> >> If I've understood correctly 4.6 looks quite similar to what we do
> >> already using the <KEYGEN> tag.  In this case the IdP can create a
> >> certificate that points to their own site, in which case the public
> >> key lookup can be done internally.
> >
> > Could you send a link to a description of what you do with the
> > <KEYGEN> tag?
> 
> If you look at http://webid.info/ about 3 minutes 40 seconds into the
> video there's some markup.
> 
> Tho I'm not sure how well KEYGEN works with IE.
> 
> There also is an HTML5 / javascript page that creates a certificate
> here: https://webid.digitalbazaar.com/manage/
> 
> Libraries behind are open source

Thanks for the pointers.  Yes, you're right, it's similar.  In both
cases a certificate is issued automatically, and IdP == RP.

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.

Generally speaking, issuing a certificate to a party who may not own
the key pair is dangerous.  An attacker could submit to the issuer a
public key belonging to a victim, and ask the issuer to sign a bogus
certificate binding the public key to attributes chosen for the
attacker, e.g. to the attacker's email address.  Then if the attacker
can somehow trick the victim into submitting the certificate to a
relying party, the relying party may use the email address to send
email intended for the victim to the attacker's email address.

To trick the victim into submitting the bogus certificate, the
attacker may, e.g., lure the victim into requesting a certificate from
a site owned by the attacker, use the public key supplied by the
victim to get the bogus certifcate from the bona fide certificate
issuer, and return the bogus certificate as issued by the attacker's
site.  The browser may store the certificate in its certificate store
without realizing that it was provided by the wrong site.

Francisco