[cap-talk] network level designation and authorization

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Thu Jun 8 17:00:53 EDT 2006


coderman wrote:
> On 6/8/06, Stiegler, Marc D <marc.d.stiegler at hp.com> wrote:
> 
>>...
>>YURLs make it possible to do better. YURLs even make it easy to do
>>better. VPNs, on the other hand, make it impossible to do better, much
>>less easy.
> 
> let me simplify:
> 
> instead of httpsy[1], or captp[2] use a distinct VPN between service
> endpoints.  there may be only one service available at that endpoint.
> (just like a single service may be available at
> httpsy://*cl7h3f7jwyj3fvmw7jpnjfvf2xlcmayi@yurl.net/...)

This is so different from how a VPN is normally used that I would suggest
not describing it as a "VPN", even if the intention is to use crypto
protocols that are most commonly used to implement VPNs.

> if you want/need to bind an identifier to a particular VPN consider an
> IPv6 addr derived from the secure digest of a suitable peer
> identifier: (feed:7ba3:c779:e5f5:cc1a:8bc7:5fe1:ed08/16 for example,
> which can be given a petname in /etc/hosts)
> 
> want to use SHA2-256 for authentication? sorry, not available in
> httpsy.  want to avoid a DHE-RSA-* setup cost on each session /
> connection? may not be possible with either.
> 
> i am advocating simple (read: no PKI) VPNs for communication privacy
> beneath plain text YURL or VatTP mechanisms, not replacing capability
> security with all or nothing VPN like traditional perimeter security.

There isn't any particular commitment to specific crypto protocols like
TLS in the high-level design of the web-calculus or CapTP/VatTP, if that
is what you are worried about.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>




More information about the cap-talk mailing list