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