On 02/03/2014 10:55 PM, Hauke Laging wrote: > This idea came to my mind while I was wondering why several CAs offer > free (but rather useless...) certificates for X.509 but not for OpenPGP. > Whatever they do with X.509 can be done with OpenPGP, too (e.g. setting > an expiration date for the signature). How much effort can it be to > offer both?
I'd also be interested in a CA that is willing to certify a public key
with both the X.509 and OpenPGP certificate formats.
> Now my point: Keys can be converted from one format to the other. The
> fingerprint changes but obviously the keygrip doesn't. I believe it
> would make a lot of sense to create a connection between gpg and gpgsm
> and point gpgsm to the OS's and / or browser's root certificate pool.
> Then a CA could offer its certificate in OpenPGP format (even conforming
> to some new "standard" which makes it easier to detect this special kind
> of certificate e.g. by using a comment or signature notation pointing to
> the related X.509 certificate),
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 (OID:
1.3.6.1.4.1.3401.8.1.1), which is the creation date of the key (in
seconds since the UNIX epoch). given the value from this extension and
the public key information, you can reconstruct the key's OpenPGP
fingerprint, and from the OpenPGP fingerprint, you can find it on the
keyservers.
I've been meaning to write a patch to make it easy to add this extension
via GnuTLS's certtool, but i haven't gotten around to it for well over a
year now :(
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 on a self-sig (presumably a self-sig
over the OpenPGP User ID that matches the X.509 Subject or something).
> 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.
> By doing so the pre-installed CA pool would become valuable for OpenPGP,
> too, and it would make sense for the CAs to offer certifications for
> OpenPGP certificates, too.
I think these two questions are distinct. 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).
> Maybe there are other reasons for some CAs, too. But I assume this would
> be rather little effort and could close much of the gap to S/MIME's
> convenience.
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.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
