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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
