<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Replacing the trust model with an improved system would seem to require rewriting the S/MIME</div>

implementation in every client.</blockquote><div><br></div><div>Allowing multiple signatures to be attached to a mail and then teaching email clients to only show "Valid signature" if there are enough probably just involves new code rather than rewriting much existing code. But yes it'd require changes to the clients.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've also never understood how keys<br>
are supposed to be distributed for global communication in S/MIME or<br>
if there's even a standard way to do this.<br></blockquote><div><br></div><div>The way Mail.app seems to do it (not tried Thunderbird) is that when you get a signed email, it saves the certificate to your local store. Once you've received a signed message from someone your emails to them will be automatically encrypted, but <i>only if you are also signing your mails</i>. The apps don't like you sending unsigned email encrypted to someone else, which is annoying.</div>
<div><br></div><div>So key distribution is basically decentralised and highly scalable, because once you got your certificate issued there are no central servers involved again, just email attachments. This seems like an attractive quality. In particular it prevents any third party servers learning when you opened mail.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I mainly chose OpenPGP over S/MIME because I can extend it without<br>
depending on CAs to not reject certificates with new features</blockquote><div><br></div><div>Yes, from an innovation/extensibility standpoint it's unfortunate that CA's won't sign things they don't understand, although I understand why they won't from a security POV (I probably wouldn't sign opaque data structures that could mean anything either....). However for just adding thresholding the certs can be the same, I'd think? You just need >1 of them.</div>
<div><br></div><div>Running a cheesy/low security CA is not very hard, it could be done on AppEngine. I guess if cool new features were created and prototyped, existing CA's could be persuaded to support new features. It's good business for them - if the new features increase demand for certs, they make more money.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">btw, Phillip Hallman-Baker is working on an S/MIME based system which<br>
also requires plenty of new infrastructure:<br>
<br>
<a href="http://prismproof.org/resources.html#specifications" target="_blank">http://prismproof.org/resources.html#specification</a></blockquote><div><br></div><div>Thanks, will check it out. </div></div></div></div>