Re: WebID, BrowserID and NSTIC

>The browser may store the certificate in its certificate store
without realizing that it was provided by the wrong site.

Is the risk associated with this greater when the public key for both
real and bogus certs are the same than it would be if different keys
were used in each?

On Thu, Jul 28, 2011 at 5:34 PM, Francisco Corella <fcorella@pomcor.com> wrote:
> 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
>
>

Received on Friday, 29 July 2011 11:49:45 UTC