On 3-Mar-06, at 12:00 PM, Robert Yates wrote:
Correct. With dmd0 the enterprise would have to put its Homesite
(HS) endpoint out in the DMZ and punch a hole through the
firewall so that the HS code can talk to the enterprise IdM
stack. It was a deliberate compromise to simplify the
implementation of a Membersite (MS).
I understand the compromise and yes, so monster can verify messages
from acme, but how does acme verify messages from monster? Is it
acceptable for enterprises to allow their servers to access the
internet?
Good question. My experience is that it is often the case, but I
don't know for sure.
For sure digital signatures and certificates are a solution, but
I'm not sure I'd go about it in exactly that way.
I guess what I'm asking here is a scope question. Is it within the
scope of DIX to allow the message signature to be a signature that
can be verified without a remote call? and if it isn't within the
scope of core, is it expected that an extension to the core could
do it?
I think making PKI a requirement would be a mistake for DIX. I think
PKI is a logical extension.
Your example can be solved without PKI in this way though:
Internally at acme.com, intranet.acme.com resolves to the Homesite.
Externally, intranet.acme.com resolves to a host that provides only
capability discovery and message verification services. The internal
and external hosts share a secret used to respectively sign and
verify messages.
We have a demo of a Firefox plug-in where the data is on the user
machine, and there is a server that shares a secret with the user's
machine, that is able to verify messages. ie. this works. :)
-- Dick
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
