making the X.509 infrastructure available for OpenPGP

[Hauke Laging]

Am Mi 05.02.2014, 11:23:24 schrieb Werner Koch:

> In general it does not make sense to use the same key - there is no
> advantage.

I think that is not correct. It is today but not from the perspective of 
my proposal.

a) If a CA uses the same key in both formats then we can get the 
advantage which I have explained first: Enabling an X.509 CA to make 
useful OpenPGP certifications.

b) If normal users convert their X.509 certificate to OpenPGP then the 
respective CA could automatically create a signature for it as Peter has 
explained. I didn't think of that when starting this thread. Some detail 
questions arise: Which keys shall be the same? Doesn't make sense to 
demand that an X.509 key is the same like an OpenPGP offline mainkey. 
Doesn't make sense to demand avoiding offline mainkeys, too. So the best 
way would probably be to require just a subkey to be the same. I assume 
the current conversion tools are not capable of that yet but that would 
not be a problem for long. In most cases being reachable via both 
standards is an advantage. That is valid for both current OpenPGP-only 
users and S/MIME-only users.

c) The other way round – an OpenPGP certificate is converted to X.509 – 
would probably affect less people but would have the analogous advantage 
like the one above: If somebody uses OpenPGP only and gets a 
certification by an X.509 CA for it (made possible by (a)) then he could 
open his communication to the S/MIME world easily if the CA offers to 
certify the same key in both formats. In the S/MIME world this would 
have an advantage (for the contacts of this user) over getting an 
independent certificate because (only) the OpenPGP version probably has 
more certifications than just the one by the CA so the authenticity 
becomes more probable. That is a less radical version of dkg's remark: 
Using OpenPGP's certification capabilities in the S/MIME world.

Nobody would be forced to trust any CA. The CA problems would be 
avoided. But the one single important argument for using S/MIME would be 
destroyed. I believe that the OpenPGP community must be interested in 
getting this argument – ease of use (with respect to key verification) – 
out of the way. More or less the whole official German computer science 
community at the universities is preaching S/MIME for exactly this 
reason:

a) The DFN offers X.509 service only.

b) The Fakultätentag Informatik has published a statement about a crypto 
culture at the universities after Snowden:
http://www.ft-informatik.de/uploads/tx_sbdownloader/Resolution_SicheresNetz.pdf

c) The GI (Gesellschaft für Informatik) is preparing a very similar 
statement.

A CS professor at Berlin's biggest university (more or less the biggest 
one in Germany) has even told me that he doesn't want me to organize 
OpenPGP courses there! That is the situation.

Does anyone here dare claim that we can get the majority of the people 
to use crypto (read: OpenPGP) without the help of the universities? That 
we can get the schools teach OpenPGP if the universities manage to make 
most crypto-using students use S/MIME?

From the perspective of spreading OpenPGP it seems quite dangerous to me 
to ignore the CAs (for "political" reasons or whyever). Of course, using 
OpenPGP does not morally oblige someone to help spread it. But I think 
it would be fair not just to say something like "I don't care about CAs" 
but to add "I don't care whether OpenPGP or X.509 gets the new crypto 
users". Of course, someone could both not care about CAs and be 
interested in spreading OpenPGP but that attitude would rise some very 
interesting questions.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140206/d4efa961/attachment.sig>