Sam Hartman <[EMAIL PROTECTED]> writes: > I'm sure someone out there is going to claim that Kerberos is a > horrible fit for this and that it is too complicated. I encourage you > to specify an alternative in at least as much detail as I have done so > we can compare the complexity, functionality, reuse of technology and > ease of deployment of proposals. While any comments are welcome, > alternative proposals or explanations of how I got use cases wrong may > make constructive discussion easier than comments of the form "this > sucks."
Sam, Well, it certainly would be straightforward to write up an alternative proposal using some other underlying technology (X.509 ACs, S/MIME, SSL/TLS client auth, etc.). I'm sure that that would have advantages and disadvantages vis-a-vis this proposal. However, I submit that we're not at the point where that level of analysis is helpful; rather, we need to work out what general kind of system architecture we want to have and only then will we have a framework for figuring out what kind of protocol to build. To that end, my next message will focus on trying to work through those issues. -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
