Re: making the X.509 infrastructure available for OpenPGP

[Daniel Kahn Gillmor]

On 02/04/2014 12:36 PM, Hauke Laging wrote:
>> 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.

if the X.509 certificate is already available, nothing else needs to be
done.  you can compare the MPIs for the public key directly.

> Using a different key would not make sense.

why not?  many of the main cartel CAs routinely set up special keys for
sub-CAs whose job is to make certain kinds of certifications.  Perhaps
such a sub-CA could be made for issuing OpenPGP certifications?

> 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.

I'd love to see it the other way around, actually (though maybe i'm
misunderstanding you again) -- It would be great to use S/MIME as the
message transport and encapsulation, but use OpenPGP for the certificate
model.  This takes advantage of all the existing message parsing and
packaging in any existing S/MIME client, and reduces OpenPGP support to
a key management and certificate validation plugin.

To do this, i'd likely want to add a pair of S/MIME-specific subkeys to
my OpenPGP certificate (one for encryption, one for signing), so that i
can avoid re-using key material across different cryptographic messaging
schemes (i.e. not use the same signing key for both OpenPGP messages and
S/MIME messages).

Werner recently (in message ID 87zjmv127f@vigenere.g10code.de)
indicated his acceptance of a notation named extended-us...@gnupg.org
with a value that can be set to "bitcoin".  Maybe the same notation
could be used to indicate "s/mime-sign" or "s/mime-encrypt" for these
sorts of keys?

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Hauke Laging]

Am Di 04.02.2014, 21:05:10 schrieb Werner Koch:
> On Tue,  4 Feb 2014 17:09, d...@fifthhorseman.net said:
> > 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
> PGP does this.  IIRC, Hal Finney once posted the specs for this to the
> OpenPGP WG.

Wow. Does that mean that PGP can verify OpenPGP keys with X.509 
certificates (in combination with a related OpenPGP certificate)? Or is 
this just a "theoretical" feature?

Are there reasons (beside the obvious effort and work budget) for not 
having implemented this in GnuPG?


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

Re: making the X.509 infrastructure available for OpenPGP

[Hauke Laging]

Am Di 04.02.2014, 19:38:07 schrieb Peter Lebbing:

> And CACert still isn't in the default
> trusted root bundle on quite some systems, I believe.

And will probably "never" be.


> extending the trust in that broken model to OpenPGP

That is not what I suggest. You can assign certification trust to any 
key. Why should this of all keys not be done with certain CA keys?

In contrast to the X.509 approach I would not skip the user's trust 
decision. And an important difference is that you could limit the CA to 
marginal trust.

There is an advantage even if you do not assign positive certification 
trust to the CA key: You see a valid CA signature on the certificate to 
be verified and can make it valid yourself.

Of course, it would be nice if you did not have to make a completely 
independent signature on the UID but could sign this one CA signature, 
thus empowering the CA signature to make the key valid. The advantages 
would be that

1) the CA cannot make keys valid without your explicit approval

2) in contrast to a signature by your own key this signature would 
become invalid if the CA revoked it. The RfC defines signatures over 
signatures but I guess this currently is not used (except for 
revocations).


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

Re: MUA "automatically signs keys"?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Friday 31 January 2014 at 9:24:17 AM, in
, Steve Jones wrote:



> Well the conventions of use, for example the key
> signing party protocol, requires photographic id. If I
> publicly sign a key it has to be in line with how I
> expect others to interpret it. Policies and notations
> on signatures go some way to alleviate that but only if
> the tools support it.

Surely if others interpret it differently than how you publicly state
you mean it, that's their own look-out.



> To me, you are just an email address, for
> all I know you're a dozen different people spoofing
> emails to the list. If all your mails are signed with
> the same key then I can at least assume all those
> people are working in concert :-)

I think all my emails to this list are signed with the same key. (-;



> The issue is that the tools around OpenPGP use are
> designed around the idea that it's for verifying some
> fixed identity, whereas in this case it's continuity of
> identity that's more important.

You mean it doesn't matter *who* I am as long as I am the same person
you corresponded with before? Apart from certain narrow
legally-defined situations, that's fairly general in real life as well
as online.



> If your key had dozens
> of signatures at the persona level going back a few
> years then I'd have a reasonable belief that you're not
> just a brand new identity created for mischievousness

If you were that worried, you could check the list archives for
signed postings from MFPA.



> With notations you get a system of
> distributed tagging, where identity becomes a matter of
> a collection of attested to attributes. Obviously this
> could create a lot of noise so you'd have a limited set
> of folks (including ephemeral Internet folks) who's
> tags you trust, probably the same people who's
> signatures you trust - which is handy. :-)

Would they "probably" be the same folks? Or would the people whose
signatures you trust be akin to those you would have round for a meal,
whereas those whose tags you trust would be more like people with whom
you'd go out for a pint?



> My mail client, and all the others I've used, is only
> interested in whether I, or someone else, has certified
> that MFPA is your real name.

Any I have used is only interested in whether the key is valid. My
local signature makes it valid but gives no clue about whether I know
somebody's real name.



> Certainly. This BTW is why I think anonymous
> cryptocurrency is a daft idea

Why do you need to know who the other person was in a Butcoin
transaction?



> True, "This person is a police officer and would like
> to know where you were last night," might lead you to
> wanting to see id.

It might also lead to a point-blank refusal to enter any discussion.


- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

Why is the universe here? Well, where else would it be?
-BEGIN PGP SIGNATURE-

iPQEAQEKAF4FAlLxTndXFIAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5pOTkEAJCgeer2dfUk73oLg+x4Os9GYfcpkRDHIbAi
yysyZcESOpZ9fMfRahVSb6YoZc87WEc2uHJAizsOaMelondTAYHTKV72KsGymd+q
wh+ZEuxgIEjYA5VjpQ9jjp/38+eUb/ZkvP3uSoHe9x1s3lHl6sdulcSKkvj1Rctz
FoGEaIJ4
=Nbk9
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Werner Koch]

On Tue,  4 Feb 2014 17:09, d...@fifthhorseman.net said:

> 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

PGP does this.  IIRC, Hal Finney once posted the specs for this to the
OpenPGP WG.  Unfortunately I can't find it in my archives.  It was a
pretty obvious thing, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Peter Lebbing]

On 04/02/14 17:09, Daniel Kahn Gillmor wrote:
> 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).

FWIW, CACert signs OpenPGP keys of verified people with key 0xD2BB0D0165D0FD58
if you want them to. Since it's 1024-bit DSA, it's a bit dated in some respects.
And CACert still isn't in the default trusted root bundle on quite some systems,
I believe.

With regard to this discussion: I'd rather see the CA model replaced by
something a little more trustworthy than extending the trust in that broken
model to OpenPGP. Monkeysphere comes to mind.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Melvin Carvalho]

On 4 February 2014 15:47, Daniel Kahn Gillmor  wrote:

> On 02/04/2014 09:01 AM, Mark H. Wood wrote:
> > Having said that, you might look at how OpenSSH has included X.509
> > certificates in its operation.  There is precedent for something like
> > what you suggest.
>
> fwiw, the answer here is "they haven't".  Roumen Petrov's X.509 patches
> remain outside of OpenSSH mainline, and there seems to be very little
> chance for upstream adoption.  Some distributions may include those
> patches, but not all of them, and upstream has held the line against
> them, even implementing their own certificate format instead of adopting
> X.509.
>

Any reason why this might be?

FWIW: I have converted my RSA GPG key into a self signed X.509 certificate,
which I display on my homepage.  Although there's no official web or trust,
it has links in, and links out, to other people's identities (and keys)
forming a mini WOT, in the same sense that a search engine might use links
in and links out as a social signal.


>
> --dkg
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Melvin Carvalho]

On 4 February 2014 15:47, Daniel Kahn Gillmor  wrote:

> On 02/04/2014 09:01 AM, Mark H. Wood wrote:
> > Having said that, you might look at how OpenSSH has included X.509
> > certificates in its operation.  There is precedent for something like
> > what you suggest.
>
> fwiw, the answer here is "they haven't".  Roumen Petrov's X.509 patches
> remain outside of OpenSSH mainline, and there seems to be very little
> chance for upstream adoption.  Some distributions may include those
> patches, but not all of them, and upstream has held the line against
> them, even implementing their own certificate format instead of adopting
> X.509.
>

Any reason why this might be?

FWIW: I have converted my RSA GPG key into a self signed X.509 certificate,
which I display on my homepage.  Although there's no official web or trust,
it has links in, and links out, to other people's identities (and keys)
forming a mini WOT, in the same sense that a search engine might use links
in and links out as a social signal.


>
> --dkg
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 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


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

Re: making the X.509 infrastructure available for OpenPGP

[Daniel Kahn Gillmor]

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

Re: making the X.509 infrastructure available for OpenPGP

[Daniel Kahn Gillmor]

On 02/04/2014 09:01 AM, Mark H. Wood wrote:
> Having said that, you might look at how OpenSSH has included X.509
> certificates in its operation.  There is precedent for something like
> what you suggest.

fwiw, the answer here is "they haven't".  Roumen Petrov's X.509 patches
remain outside of OpenSSH mainline, and there seems to be very little
chance for upstream adoption.  Some distributions may include those
patches, but not all of them, and upstream has held the line against
them, even implementing their own certificate format instead of adopting
X.509.

--dkg



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: making the X.509 infrastructure available for OpenPGP

[Mark H. Wood]

On Tue, Feb 04, 2014 at 04:55:56AM +0100, Hauke Laging wrote:
[snip]
> 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), 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).
> 
> 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.

Assuming you trust those CAs.  All of them.

Having said that, you might look at how OpenSSH has included X.509
certificates in its operation.  There is precedent for something like
what you suggest.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users