making the X.509 infrastructure available for OpenPGP

[Hauke Laging]

Am Di 04.02.2014, 11:09:42 schrieb Daniel Kahn Gillmor:

> We have such an indicator format going in the opposite direction
> (pointing from X.509 to the related OpenPGP cert).  In particular,
> it's the X509v3 extension known as PGPExtension

Interesting, I didn't know that.


> I don't know of a formalized way to do the other mapping, but it seems
> like it would be pretty straightforward to embed the full X.509
> certificate in a notation packet

Why wouldn't the fingerprint and the DN not be enough? The whole 
approach is based on the assumption that the X.509 certificate is 
already available.


> > and GnuPG could easily realize that it
> > is the same key. This would relieve the user from the hard decision
> > whether a certificate is valid (the CAs OpenPGP certificate in this
> > case). The user would just have to decide (like with any other
> > OpenPGP certificate) whether he wants to trust this CA (and how
> > much).
> I have never heard a user wonder whether a given CA's certificate as
> shipped by their browser (for example) is valid.  At best, i've heard
> people wonder whether a given CA should be relied on ("put in the root
> store", "trusted", etc).  So i don't think the OpenPGP verification
> step gains you anything here.

You have misunderstood me: I said (or: tried to say...) quite the same. 
Because the CA key is in the root store the user need not care about it 
being valid or not. And this covers the OpenPGP variant of the key, too, 
of course. Thus the OpenPGP verification step could be skipped. The 
trust step could be skipped, too, but I would prefer to keep a question 
"This CA's key has already been verified. How much do you want to trust 
this CA?" That would reduce the risk of pre-installed certificates and 
remind users of it that they must decide whom to trust. With OpenPGP 
certifications it would also make perfect sense to set a CA to marginal 
trust.


> If there is a public CA
> that is willing to offer OpenPGP certificates, i would like to know
> about it (whether they offer them with the same key they use for
> their X.509 activities or not).

Using a different key would not make sense. And without OpenPGP being 
capable of using the X.509 CA store it makes little sense for the CAs to 
make OpenPGP certifications. So why should they be willing to do 
something obviously useless? The OpenPGP community has to make a 
technical change first (or at least to offer making that change) before 
the question whether the CAs are willing is useful.


> I'm not sure how the gap would be closed.  From my perspective, the
> S/MIME convenience stems from near-ubiquitous integrated deployment as
> much as it does from the (problematic and untrustworthy) "i don't
> have to think about it" certificate validity model.

That's my opinion, too. And exactly that can be taken over to OpenPGP. 
Integrated deployment is already there, we just need the technical 
bridge from X.509 to OpenPGP. And afterwards the OpenPGP certifications 
by the CAs, of course.


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/20140204/1393852e/attachment-0001.sig>