[148456] in cryptography@c2.net mail archive
Re: [Cryptography] Size of the PGP userbase?
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Sat Dec 14 16:03:11 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52AC010C.3030606@iang.org>
Date: Sat, 14 Dec 2013 11:44:36 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: ianG <iang@iang.org>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>,
Jon Callas <jon@callas.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6867608129127475465==
Content-Type: multipart/alternative; boundary=001a11c24a94514faa04ed814b61
--001a11c24a94514faa04ed814b61
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Dec 14, 2013 at 1:56 AM, ianG <iang@iang.org> wrote:
> On 13/12/13 21:27 PM, Jon Callas wrote:
>
>> I suspect you might be better off counting messages encrypted rather than
>>> users. Anyone got an angle into a message tracking service?
>>>
>>
>> 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.
>>
>
>
> 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.
>
> 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...
I don't think the use figures are a good basis for choosing formats.
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.
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.
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.
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.
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.
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.
1) It is the format supported by the legacy email infrastructure.
1a) Existing mail clients can send and receive S/MIME mail without
modification
1b) Every MTA provider of consequence has made sure that their equipment
works with S/MIME and supports use.
2) It is the format that the IETF has maintained.
PGP/MIME never got the same attention as S/MIME and has not been made to
work as well.
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.
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.
4) We can use the WebPKI for authenticating corporate mail.
I think that a mail message that comes from Bank of America should come on
an impossible to forge Bank of America letterhead.
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.
5) PGP users are more likely to move than corporate S/MIME users.
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.
People who use PGP are using it to protect their privacy, not to follow
some ideological crusade that requires that particular message encoding.
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.
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.
--
Website: http://hallambaker.com/
--001a11c24a94514faa04ed814b61
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Dec 14, 2013 at 1:56 AM, ianG <span dir=3D"ltr"><<a href=
=3D"mailto:iang@iang.org" target=3D"_blank">iang@iang.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 13/12/13 21:27 PM, Jon Callas wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect you might be better off counting messages encrypted rather than u=
sers. =A0Anyone 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 mess=
ages. Of that, about 85% are decryption/verify events. My results are obvio=
usly 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! =A0So you could measure the ratio of PGP to S/MIME usage by message fr=
om that. =A0You could also count the number of distinct users for each popu=
lation.<br>
<br>
As a proxy for PGP population, if you have the S/MIME population estimate f=
rom somewhere, multiple that with the ratio, and you have an estimate. =A0S=
tandard 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 in=
frastructure. So during the transition period PGP users will acquire the ab=
ility 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 th=
e new features I am adding for frictionless usability then they are going t=
o have either generate a new key set or run the key generation tool to gene=
rate 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 separat=
e 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 se=
parate. 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, other=
wise they could use it to create a 'self-endorsement' assertion acc=
rediting 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 a=
ll 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 se=
nse 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.=A0</div>
<div><br></div><div>1a) Existing mail clients can send and receive S/MIME m=
ail without modification</div><div>1b) Every MTA provider of consequence ha=
s 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 attent=
ion as S/MIME and has not been made to work as well.=A0</div><div><br></div=
>
<div><br></div><div>3) Adding the necessary support for S/MIME format to us=
e 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 fo=
rmat makes use of this. Adding the necessary support for PGP keys in CMS/PK=
CS#7 is trivial. All that you need to do is to put the key identifier of th=
e recipient into the message.</div>
<div><br></div><div><br></div><div>4) We can use the WebPKI for authenticat=
ing corporate mail.</div><div><br></div><div>I think that a mail message th=
at 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 ex=
ists and so does much of the policy infrastructure. The signature would hav=
e to be backed by a certificate that is issued by a CA and the EV validatio=
n criteria would apply and the holder would have to prove that they had obt=
ained the corresponding trademark and we would probably have some transpare=
ncy requirement.</div>
<div><br></div><div><br></div><div>5) PGP users are more likely to move tha=
n 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 ther=
e are corporate users who demand it. This despite the fact that XP is the l=
ast of the legacy MSDOS versions of Windows and is intrinsically insecure.=
=A0</div>
<div><br></div><div>People who use PGP are using it to protect their privac=
y, not to follow some ideological crusade that requires that particular mes=
sage 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 w=
ith the authentication format. Only the parts of the message inside the bou=
ndaries 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 c=
ritical failure in S/MIME is that it only supported the CA trust provider m=
odel.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>
--001a11c24a94514faa04ed814b61--
--===============6867608129127475465==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============6867608129127475465==--
