<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 14, 2013 at 1:56 AM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 13/12/13 21:27 PM, Jon Callas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect you might be better off counting messages encrypted rather than users.  Anyone got an angle into a message tracking service?<br>
</blockquote>
<br>
The stats on my server show that about 1.5% to 2% are encrypted/signed messages. Of that, about 85% are decryption/verify events. My results are obviously going to be more than the population at-large because I'm running an encryption server, but anecdotally, almost all of those are OpenPGP or S/MIME signature verifications.<br>

</blockquote>
<br>
<br></div>
Aha!  So you could measure the ratio of PGP to S/MIME usage by message from that.  You could also count the number of distinct users for each population.<br>
<br>
As a proxy for PGP population, if you have the S/MIME population estimate from somewhere, multiple that with the ratio, and you have an estimate.  Standard marketing calculations...</blockquote><div><br></div><div>I don't think the use figures are a good basis for choosing formats.</div>
<div><br></div><div>The objective is to go from two separate userbases that can't communicate without adopting the other's code to a single infrastructure. So during the transition period PGP users will acquire the ability to send in S/MIME format and vice versa.</div>
<div><br></div><div><br></div><div>If people want to make use of some of the new features I am adding for frictionless usability then they are going to have either generate a new key set or run the key generation tool to generate a policy file using the old one.</div>
<div><br></div><div>One of the things I am doing to make crypto simpler is to remove unnecessary options. I don't give the option of using separate keys for encryption and signature, it is a requirement. I don't give people a choice of RSA key size, it is 2048 bits.</div>
<div><br></div><div>I also require key signing and end-entity keys to be separate. So the way I would support someone's legacy PGP key is that if it is RSA2048 then they could generate encryption and signature keys, otherwise they could use it to create a 'self-endorsement' assertion accrediting a newly generated key set.</div>
<div><br></div><div><br></div><div>In the transition period we will need to support both formats and any successor trust infrastructure must support all the use cases of the old one. The US DoD is not going to switch to a Web of Trust scheme, neither is any enterprise user. An RA model makes best sense for those applications just as Web o' Trust makes better sense than CA for many individual users.</div>
<div><br></div><div>But when it comes to formats, I can't see the value of keeping Blu-Ray and HD-DVD. S/MIME is the better packaging format for a lot of reasons.</div><div><br></div><div>1) It is the format supported by the legacy email infrastructure. </div>
<div><br></div><div>1a) Existing mail clients can send and receive S/MIME mail without modification</div><div>1b) Every MTA provider of consequence has made sure that their equipment works with S/MIME and supports use.</div>
<div><br></div><div><br></div></div><div>2) It is the format that the IETF has maintained.</div><div><br></div><div>PGP/MIME never got the same attention as S/MIME and has not been made to work as well. </div><div><br></div>
<div><br></div><div>3) Adding the necessary support for S/MIME format to use PGP keys is much easier than adding the necessary support for PKIX certs in PGP format.</div><div><br></div><div>PGP is a key centric PKI and the format makes use of this. Adding the necessary support for PGP keys in CMS/PKCS#7 is trivial. All that you need to do is to put the key identifier of the recipient into the message.</div>
<div><br></div><div><br></div><div>4) We can use the WebPKI for authenticating corporate mail.</div><div><br></div><div>I think that a mail message that comes from Bank of America should come on an impossible to forge Bank of America letterhead.</div>
<div><br></div><div>The technical infrastructure to support this already exists and so does much of the policy infrastructure. The signature would have to be backed by a certificate that is issued by a CA and the EV validation criteria would apply and the holder would have to prove that they had obtained the corresponding trademark and we would probably have some transparency requirement.</div>
<div><br></div><div><br></div><div>5) PGP users are more likely to move than corporate S/MIME users.</div><div><br></div><div>If we are going to merge formats then one group has to move. Enterprises move much slower than real users. The only reason you can still buy a copy of Windows XP is that there are corporate users who demand it. This despite the fact that XP is the last of the legacy MSDOS versions of Windows and is intrinsically insecure. </div>
<div><br></div><div>People who use PGP are using it to protect their privacy, not to follow some ideological crusade that requires that particular message encoding.</div><div><br></div><div><br></div><div>I can't see any long term value to the legacy PGP format and I can see plenty of problems with the authentication format. Only the parts of the message inside the boundaries are authenticated.</div>
<div><br></div><div>The heart of PGP is the peer endorsement model. Anyone can endorse a key for someone else, everyone can be a trust provider. The critical failure in S/MIME is that it only supported the CA trust provider model.</div>
<div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>