>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> Does this seem a reasonable approach in some circumstances?
Jim> Are there circumstances you can see where this would be
Jim> unreasonable?
So, technically it's a lot easier to do this with certs for which you
don't share a trust anchor than for TLS with anonymous DH ciphers.
Mostly implementation issues at fault; end-point channel bindings are
more widely implemented than unique for TLS.
The general model is sound and is one Nico and I have been working on
for years.
It means you're really trusting EAP channel binding. It means whoever
runs your ABFAB actually needs to do a quality job of validating
servers. However they may have a smaller problem than a global PKI to
solve so it may be easir for them to do that.
It's unreasonable if you want to validate the server before disclosing
what abfab realm you want to talk to.
It's unreasonable if your implementation doesn't let you fiddle with TLS
validation and defer it until after CB so you can suppress if CB
succeeeds.
It may be unreasonable if the client machine needs to trust the server
independently of the user at the client machine. Often the client
machine will not be able to establish trust in the ABFAB architecture.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
