> Well, it's also the availability of the right signature > facility in the > myriad email clients people use. I disagree here, I believe it is a case of supporting the overwhelming majority of the platforms with software that is freely available and free. I don't believe that we should consider support for Open Genera to be a 'must support' issue. Years ago people used to whinge when someone sent a MIME attachment of 10K or so because it took too long to download over a 300 baud modem. I don't think it is a bad thing to consider that high bandwidth connectivity is still a constrained resource absent in many less developed parts of the world. However the complaints about using MIME never come from those quarters. > I could write that up in an internet > draft if folks > >think it makes sense. That would be a more global procedure > that didn't > >require a PKI and only addressed spoofed addresses. > > > Wasn't me... The problem is not the PKI, the problem is the directory. Deployment of PKI is easy. It is the Directory baggage that people foisted onto PKI that is the failure. X.500 has set us back more than the NSA crypto export regulations ever did. LDAP merely compounds the problem, building failure on top of failure. We need a DNS linked PKI, not a directory linked PKI. We need a PKI that only cares about the addresses the applications route on. The idea of using human names for PKI is bogus. The directory PKI model fails for the Internet for many reasons. First taxonomic organization is a broken concept. No real world information is stuctured in that fashion, not even genealogies (cousins marry cousins). The reason that so many enterprise directory projects are fiascos is that they are trying to fit data into a representation that is simply inappropriate. The other main reason that directories are a failure for Internet PKI is that they are exclusively an internal data resource. VeriSign has an employee directory accessible from the inside of the company. There is no way it is ever going to be accessible from the outside. At the Internet level trust relationships are complex, they are certainly not hierarchical. Trying to store that data in a taxanomic sturcture then do path discovery is nonsense on stilts. Linking the PKI to the DNS completes the picture. I want to send Fred Baker an email, well I had better know his email address first. My email client can follow an SRV record from cisco.com to find an XKMS service for cisco.com where I can ask 'what key should I use to send an encrypted S/MIME email to fred@cisco.com'. Allowing organizations to find out that Fred@cisco.com is still working for Cisco is actually a security improvement. It means that Office Max can shut off his personal stationary account ordering privs the minute he leaves Cisco. Don't reject the leverage that public key provides just because you don't like the package people tried to wrap arround it. The protocol you describe requires state and is simply not deployable for large systems like hotmail. It would be nice if the IETF could get ahead of the curve this time instead of being the brake. We still have members of the IESG speaking to security forums disputing the utility of network security measures such as firewalls even after Steve became a security area director. We need to shift towards a comprehensive multi-level security approach which accepts that there are problems that cannot be addressed by the end to end argument. Real users are saying that SPAM is their number one internet related problem today. Classify it how you like but deal with it with a security mentality. The spamers are seriously degrading the utility of email. We need a short term approach to mitigate the problem (filtering) and long term approaches that have the potential to put them out of business. Authenticating the good signal is completely complimentary with rejecting the bad. Phill
Attachment:
smime.p7s
Description: application/pkcs7-signature