Announcing Droplets

[Mark S. Miller]

At 07:42 PM 9/28/99 , Tyler Close wrote:
>I think I am understanding something here that I didn't
>before. Are you suggesting that inter-Cistern communication
>is not possible? If so, then I need to disagree.
>...
>To make an analogy to the E case, the web site name is the
>VatID. Using the existing PKI, we can validate the
>encryption key given by the site. Granted, using the
>existing PKI sucks compared to E's VatID, but on the other
>hand, the existing PKI exists.

You are correct that I was indeed misunderstanding the logic of your URLs 
in this way.  I was (and am) taking the swiss number seriously, as 
providing the equivalent of the E's swiss numbers.  However, I was not 
taking the HTTPS URL authentication seriously.  Turns out, I don't know 
what the browser is supposed to be doing here.

When you feed an HTTPS compliant browser a URL such as

     https://www.fudco.com/blah.html

I know that it establishes an SSL link.  I know that it I then click on the 
key-or-lock-or-whatever icon (or otherwise request security info for the 
current page) I find the server's authenticated identity according to 
conventional CA-hierarchy notions, rooted in identities my browser is 
configured to trust as a naming root.  However, ignoring the requestable 
security info, what authentication does the browser do of the URL 
itself?  If a conforming browser (or url-fetching library, for that matter) 
successfully dereferences that URL, in what sense can we say we know we are 
getting data from the real fudco.com?

If there is an adequate answer, then you are correct.  If there isn't, then 
both of us were wrong.  Without URL authentication, you scheme doesn't even 
work single-VAT unless we assume the user looks at the security 
info.  Having inspected the security info once, how often must they 
recheck?  HTTP is connectionless.  How does this effect the stability of 
assurances gained about an HTTPS connection?  I am ignorant here.


         Cheers,
         --MarkM