Sam Hartman wrote: > Many X.509 smart cards have no UI at all. I agree smart cards need to > be supported. The goal of 4.1 is to say that we must support > passwords and that solutions that only work with smart cards are not > sufficient. >
Once again I think we agree, but in as much as you're using MUSTs for one and "desirable" for another I wasn't sure. I sure as heck don't like the idea of a smart card without a UI, and an anti-phishing defense is useless unless there is mutual authentication, as you clearly point out. > Eliot> Furthermore, in section 4.5, (1) simply having X.509 server > certificates > Eliot> is not sufficient defense due to iDNS (homoglyphic?) attacks and > the > Eliot> like. I think there is no perfect way to accomplish 4.5. > > Server certs are not sufficient for humans to verify for the reasons you > site. > However if a name is included in another protocol message then the binding > between that name and the server cert can be secured. > Perhaps I'm not well enough versed to understand why this would be the case, unless the other end can prove itself in some meaningful way in the next phase that the user would actually understand. And even then I'm not sure that solves MITM. > I think it is quite possible to accomplish 4.5 in the case where you > have an existing relationship with a site based on shared secrets. > > Eliot> Section 4.6 assumes that there is a third party identity provider. > This > Eliot> needn't be the case, but if it is, it is sufficient to have a > name, a > Eliot> nonce, and a public/private key pair, is it not? > Consider your classic case of a Secure Computing 3DES encryption with serial along with a secure "name" that has associated with it a pkp that was generated during enrollment/registration. There is no 3rd party, with the possible exception of enrollment time and other OAMP operations. The drawback is that the "name" in question needs to be known by both ends. Classically this is the username. Eliot _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
