cab forum guide; multiple handshakes vs. signed XRD + DANE; Lampson joint authority: cloud providers and webids

Not really sure to which issue this note relates. It was motivated by
WebID-ISSUE-28 though.

 

CAB forum guide to be found at http://www.cabforum.org/Guidelines_v1_3.pdf;
and of course our Opera friends can brief us; as insiders, there. There may
be confidences though, that prevent full disclosure.

 

Given issue 28, I'm assuming that any EV cert addresses the threat of SSL
MITM intermediaries - in the sense that those corporate SSL MITM sites using
such as the Microsoft Threat Management Gateway (TMG) while having an EV
cert themselves may not sign another site's EV public key (using the TMG's
"authority spoofing" power). After all, that undermines the whole point of
EV, since no green address bar would be present in the browser behind the
inspecting-firewall.

 

(That assumption can be challenged, note.)

 

But, logically, this would provide a way to classify entities into 2 groups:
those who are prohibited and those who are not. Perhaps we can allow some
[other] folks to resign EV certs, usefully. We take the value of SSL MITMing
that re-signs server cert on the fly, and apply its core method: resigning
the server certs of others. RFC 1422 (PEM) has long supported the notion
that one public key can be signed by multiple authorities (if useful.)

 

Let's link together (i) per FOAF+SSL, the use of SSL server certs to
indicate "standing" of profiles to resource servers, (ii) the use of
multiple handshakes on a single TCP connection, and (ii) the CAB Forum's EV
cert.

 

Imagine that a cloud provider supporting webid protocol hosts 1000 profiles,
providing a 1001 endpoints to resource servers verifying webid claims. On
#1001 it acts like an EV Cert site; but never provide any profiles. On #1 -
#1000 it provides profiles. It's just a webserver with 1001 virtual hosts,
and logically 1001 server certs.

 

The provider fins itself normally responding as an SSL server to the some
https library client used by the resource server, which populates the SNI
clientHello extension with the webid claim's URI authority field. The
provider provides the #456th SSL server chain in response (say) and the
associated profile document.

 

Which SSL server cert is the #456th?

 

But perhaps we can learn from Lampson's authentication logic, and then "get
smarter" with SSL - leveraging the SSL protocol's ability to perform 2
handshakes in sequence; supplying 2 server certs thereby; and implementing
Lampson's joint authority rule. The idea is that the combination of the 2
server certs one 1 SSL channel states, after 2 handshakes are complete : I
have joint authority with user to speak for the status of this profile (and
its embedded public key material)

 

On handshake 1 (of 2), the virtual host supplies the cloud endpoint's EV
Cert "EVCA<<EVpub>>" - intending to make normal EV world representations. As
SSL server, it immediately forces a second SSL handshake. This time it
supplies profileuser<<EVpub>>. This expresses a user's consent to EVpub to
speak for it, something EV organization cannot spoof.

 

(" X<<Y>>" is X.509 shorthand for X signs Y's public key, issuing a cert )

 

With this kind of design theory, we could start to offer a webby version of
signed XRDs, and host-metas. Just as W3C asserted that XRI was not conducive
to the web since URIs could do the same thing, so perhaps one might assert
that good old upgraded SSL could do that which signed XRD will do, but do it
in a more webby way. 

 

We should  remember that signed XRDs [essentially] require DNSsec zone
signatures to support the public keys that verify XRD's xmldsig signatures.
DNSsec is duplicating what CA cert certs do in SSL. (Hence DANE, from
Hoffman&co, laying the foundation for browsers to use signed XRDs as an TLS
cert-type, as an alternative to ASN.1 EE certs)

 

But, a minor "twist" of good old https with ol' server certs do the same,
staying more compatible with the TAG guidelines for the web? And, support
webid protocol at the same time?

 

We would seem to be now characterizing what role the cloud providers might
play, in the world of webids.