headers
Christoph Anton Mitterer | 1 Feb 2009 01:29
Gravatar

Re: Series of minor questions about OpenPGP 4

Sorry, I haven't seen that Peter has nearly asked the same...

On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote:
> > btw: As far as I understand this works the following way:
> > - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the
> > revocation signature AND with an earlier timestamp than the revocation
> > signature
> > BUT ONLY when calculated over the same data, which effectively means:
> > * Either all the 0x1Fs from the specific key (primary or sub)
> > * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID
> > but NOT:
> > * from all User IDs or even all 0x10-0x13s and 0x1Fs

> > - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME
> > creator as the revocation signature AND with an earlier timestamp than
> > the revocation signature
> > BUT ONLY when calculated over the same data, which effectively means:
> > * Only on the specific subkey, not from the other subkeys
I've seen you other mail that for subkeys this isn't possible at all, as
only one 0x18 and corresponding revocation is allowed.

> > - a 0x20 recovers everything and cannot be undone (with timestamp
> > tricks)
> >
> > Is this correct?
> 
> Not exactly.  A revocation revokes *one* signature.  Given this:
> 
>    Signature (timestamp 1)
>    Signature (timestamp 2)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wim Lewis | 1 Feb 2009 01:30

Re: Do we need to secure our keyservers against kind of DoS Attacks


(Attention Conservation Notice: non-expert explaining why he thinks  
the current system is almost-good-enough without securing keyservers)

This is an interesting point. After thinking about it a little,  
though, I think that securing the keyserver (or the communication  
with the keyserver) isn't quite the right approach. One of the  
strengths of the PGP setup, I think, is that you don't have to trust  
the keyserver; all it's doing is making it easier for you to get  
information that you can in theory get elsewhere.

An end-to-end approach is better, IMHO. (It also protects against the  
opposite side of the equation: is Mallory secretly stripping the  
revocation certificate out of your friend's uploads to the keyserver?  
Also, I don't want to have to make trust/policy decisions based on  
how much I trust the people running the keyserver, how strong my  
trust path is to their key, and so on. That way lies X.509...)  
Notionally, I want some sort of periodic, signed communication from  
other keyholders, saying, "The official state of my key-and- 
subpackets is X. Expect another message before date Y". However, not  
all of the subpackets are really important: if I'm missing a  
signature from someone else, or an alternate user ID, I'm not going  
to trust you any *more* than if I have it. So this thing only needs  
to cover packets which reduce trust --- revocations, I guess. (Am I  
missing a scenario here?)

But is this actually any different from periodically renewing a set  
of expiring signatures? (I don't think so, but I could easily be  
missing stuff.) In which case, OpenPGP already supplies everything  
needed to prevent this sort of denial-of-key-distribution attack.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christoph Anton Mitterer | 1 Feb 2009 02:18
Gravatar

Re: Series of minor questions about OpenPGP 4

On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote:
> The point I was trying to make is a little different.  The RFC  
> specifies a (RECOMMENDed) way to handle this problem, so that the  
> extra revocations are not needed for any implementation that is  
> compliant with that advice.
Ok,.. in that case (if an implementation follows that advice, we don't
have to talk, as you're right and everything is fine :-)

>   This method with extra revocations is an  
> attempt to force non-compliant implementations into doing the right  
> thing.  I suspect this may be tilting at windmills.  These  
> implementations are already disregarding the RFC advice.  It is  
> difficult to use RFC advice to get a non-RFC advice following  
> implementation to do the right thing.
Ok I got your point,.. and the following is probably a little bit
pedantic and quibbling. The point I was trying to make is:
As this "use the most recent" is "only" a RECOMMENDS, an implementation
might not follow this advice, and would be still conforming, right?
As you've said, it's only an advice.

We cannot do anything about really-non-conforming implementations (the
ones that breaks the MUSTs and so on), so lets forget about them.

But the just plain (very) stupid ones which are compliant (and thus
would follow the revocations of the previous self-sigs, as Peter
suggested) but don't follow that advice/recommendation would break and
possibly do bad things.
And this could be avoided by following Peters ideas.

To conclude:
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Shaw | 1 Feb 2009 04:17

Re: Series of minor questions about OpenPGP 4


On Jan 31, 2009, at 6:41 PM, Peter Thomas wrote:
>>> b) when I use a 0x28 key revocation signature:
>>> Does this (according to the RFC) make the subkey forever unusable,  
>>> as
>>> above with the 0x20s?
>>> Or would issuing a subkey binding signature more recent than the  
>>> 0x28
>>> bring it (the subkey) back?
>> That's a good question.  The RFC specifies that a subkey may have one
>> (and only one) binding signature, and zero or one revocations.
> Wow,.. uhm could you please point me to the location that mandates  
> this?

Section 11.1.  But notice what that section is: Transferable Public  
Keys.  This doesn't really mean you *can't* re-sign a subkey.  It just  
means that once you *have* re-signed a subkey, you need to remove the  
old signature (and revocation, if any) before you give the key to  
anyone else.

>> Part of the design of OpenPGP is that subkeys are cheap - you should
>> be able to make new ones easily.
> That's true, of course. But it could be annoying if people expect
> particular (sub)key ids, as they're used to it (e.g. when using a
> subkey for a special role like "work" or "home").

Subkeys aren't really usable for roles.  User IDs make great roles.   
Subkeys can be used by anyone who cares to, so if you have two  
encryption keys, even though you intend one for "home" and one for  
"work", you have no way to tell me which one you want me to use, and
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Shaw | 1 Feb 2009 04:36

Re: Series of minor questions about OpenPGP 4


On Jan 31, 2009, at 8:18 PM, Christoph Anton Mitterer wrote:

> On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote:
>> The point I was trying to make is a little different.  The RFC
>> specifies a (RECOMMENDed) way to handle this problem, so that the
>> extra revocations are not needed for any implementation that is
>> compliant with that advice.
> Ok,.. in that case (if an implementation follows that advice, we don't
> have to talk, as you're right and everything is fine :-)
>
>>  This method with extra revocations is an
>> attempt to force non-compliant implementations into doing the right
>> thing.  I suspect this may be tilting at windmills.  These
>> implementations are already disregarding the RFC advice.  It is
>> difficult to use RFC advice to get a non-RFC advice following
>> implementation to do the right thing.
> Ok I got your point,.. and the following is probably a little bit
> pedantic and quibbling. The point I was trying to make is:
> As this "use the most recent" is "only" a RECOMMENDS, an  
> implementation
> might not follow this advice, and would be still conforming, right?
> As you've said, it's only an advice.
>
> We cannot do anything about really-non-conforming implementations (the
> ones that breaks the MUSTs and so on), so lets forget about them.
>
> But the just plain (very) stupid ones which are compliant (and thus
> would follow the revocations of the previous self-sigs, as Peter
> suggested) but don't follow that advice/recommendation would break and
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Shaw | 1 Feb 2009 04:36

Re: Series of minor questions about OpenPGP 4


On Jan 31, 2009, at 7:29 PM, Christoph Anton Mitterer wrote:

> Sorry, I haven't seen that Peter has nearly asked the same...
>
> On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote:
>>> btw: As far as I understand this works the following way:
>>> - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as  
>>> the
>>> revocation signature AND with an earlier timestamp than the  
>>> revocation
>>> signature
>>> BUT ONLY when calculated over the same data, which effectively  
>>> means:
>>> * Either all the 0x1Fs from the specific key (primary or sub)
>>> * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID
>>> but NOT:
>>> * from all User IDs or even all 0x10-0x13s and 0x1Fs
>
>
>>> - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the  
>>> SAME
>>> creator as the revocation signature AND with an earlier timestamp  
>>> than
>>> the revocation signature
>>> BUT ONLY when calculated over the same data, which effectively  
>>> means:
>>> * Only on the specific subkey, not from the other subkeys
> I've seen you other mail that for subkeys this isn't possible at  
> all, as
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Shaw | 1 Feb 2009 04:46

Re: Ideas on new user attribute types and image formats


On Jan 31, 2009, at 11:27 AM, Daniel Kahn Gillmor wrote:

> * I'd like to see better cryptographic verification tools that take
> advantage of OpenPGP's WoT to display human-comprehensible  
> descriptions
> of relevant trust paths to an attempted validation.  Since most people
> use graphical environments, and most people recognize people by their
> faces even more quickly than by their names, it would be great to show
> such trust paths with images in them (e.g. "Mary says that this is  
> Joe"
> is useful, but a picture of Mary saying "this is Joe" would be even  
> more
> appealing to many users).

I like this one in particular.  The WoT is one of the least understood  
parts of OpenPGP.  Doing it graphically would help.

> Plus, it would be cool ;)

Yes.

David
Permalink | Reply | 0 comments |
headers
Christoph Anton Mitterer | 1 Feb 2009 16:03
Gravatar

Re: Do we need to secure our keyservers against kind of DoS Attacks

On Sat, 2009-01-31 at 16:30 -0800, Wim Lewis wrote:
> One of the  
> strengths of the PGP setup, I think, is that you don't have to trust  
> the keyserver;
Well I think you already do this or better said, the whole PKI does it.
It's just not yet secured.

> An end-to-end approach is better, IMHO. (It also protects against the  
> opposite side of the equation: is Mallory secretly stripping the  
> revocation certificate out of your friend's uploads to the keyserver?  
> Also, I don't want to have to make trust/policy decisions based on  
> how much I trust the people running the keyserver, how strong my  
> trust path is to their key, and so on. That way lies X.509...)  
Yeah but again,.. I think you're already doing this, otherwise you'd
have to retrieve all you key updates manually from the key owners (e.g.
every day or so). Even worse, you'd also have to retrieve updates by the
signers to the keys of your keyrings, and their signers and so on..

> Notionally, I want some sort of periodic, signed communication from  
> other keyholders, saying, "The official state of my key-and- 
> subpackets is X. Expect another message before date Y".
But this is very difficult, as it's probably not enough to only get the
official state of the key of your direct contacts (see above)

> However, not  
> all of the subpackets are really important: if I'm missing a  
> signature from someone else,
But what if this signature is part of the trust path?

>  or an alternate user ID, I'm not going
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Anton Mitterer | 1 Feb 2009 18:21
Gravatar

"Roles" for subkeys?!

Hi WG!

Let me just pick the following from another thread up and fork it here:

On Sat, 2009-01-31 at 22:17 -0500, David Shaw wrote:
Subkeys aren't really usable for roles.
> I've always missed that,...

User IDs make great roles.   
> Subkeys can be used by anyone who cares to, so if you have two  
> encryption keys, even though you intend one for "home" and one for  
> "work", you have no way to tell me which one you want me to use, and  
> even if you did, I could use the other one if I wanted to.
On advantage of subkeys is that one can use them independently from the
primaries, I mean you don't need a copy of the primary private key to
decrypt data encrypted with a public encryption subkey, or you don't
need it to sign data with the secret signing subkey.
gnupg even has some options to create such crippled keys, and they're
good to use in e.g. less secure like my work PC where every sysadmin
have access to (Klaus, if you read this, it's not that I wouldn't trust
you ;) )...
So far I don't need subkey roles,... but the problem now is,...

1. When some of my LHC/LCG/Grid/etc contacts sends me encrypted data,...
he doesn't know which encryption subkey to choose, as you've said.
And thus I'll be probably unable to decrypt the message (at least at
work).

2. When I make signatures with my different subkeys, I'd like that
people see it when I used my not-so-secure work signing subkey (perhaps
(Continue reading)

Permalink | Reply | 501 comments |
headers
Daniel A. Nagy | 1 Feb 2009 18:49

Re: "Roles" for subkeys?!

Hi,

Christoph Anton Mitterer wrote:
> On advantage of subkeys is that one can use them independently from the
> primaries, I mean you don't need a copy of the primary private key to
> decrypt data encrypted with a public encryption subkey, or you don't
> need it to sign data with the secret signing subkey.
> gnupg even has some options to create such crippled keys, and they're
> good to use in e.g. less secure like my work PC where every sysadmin
> have access to (Klaus, if you read this, it's not that I wouldn't trust
> you ;) )...

As far as I know, this is the primary use case for subkeys. I have a different
signature subkey on every computer that I use and the same encryption subkey.
The primary key is not installed anywhere.

> So far I don't need subkey roles,... but the problem now is,...
> 
> 1. When some of my LHC/LCG/Grid/etc contacts sends me encrypted data,...
> he doesn't know which encryption subkey to choose, as you've said.
> And thus I'll be probably unable to decrypt the message (at least at
> work).

I think that having different encryption subkeys is pointless. While it is not
in the standard (maybe it should), all OpenPGP implementations encrypt to the
most recent valid encryption subkey.

> 2. When I make signatures with my different subkeys, I'd like that
> people see it when I used my not-so-secure work signing subkey (perhaps
> something that the user agent adds like <User ID> + "(this is my
(Continue reading)

Permalink | Reply | 501 comments |

Gmane