David Shaw wrote:
On Tue, Nov 08, 2005 at 11:41:43PM +0100, Christoph Anton Mitterer wrote:
Ok,.. you told me that the disadvantage of C-only keys would be that you
can't response to challenges. Is this the only reason?
As far as I know a challenge/response is used by some users to verify
the email of an UID before they sign it. But lots of people do not
validate this, because they think it wouldn make sense at all. E.g. if
someone uses some freemail address he could lose the address after
validation because the provider stops his service. So signing the eMail
as part of an UID does not really secure that the address is under the
controll of the keyholder, does it?
That is not how email challenges work. If someone loses their email
address, the signature is effectively invalid.
Yes,.. the person who made the signature would not notice that if the
key-owner does not revoke the uid OR if the person writes an email to
the owner, right?
If so:
-If the owner is evil, stupid, lazy, etc. he would not revoke the
invalid UID....
-and someone who makes a signature CAN NOT verify that email
periodically... of course he could,.. but most people wouldn't like it
if they'd have to answer challenges over and over again.
So the only solutions would be:
-Make challenges periodically (e.g. with something like PGP Global
Directory or a personal script or so)
-make only expiring signatures...
Right?
That's a feature, not
a flaw. When you sign an email address, you are certifying that it is
valid at that point.
Yes...
Obviously you can't certify it as valid forever.
Yes... but this IS the problem about the whole thing with
verify-email-address-when-signing, I think.
The only solution (in my opinion) are services like PGP Global Directory
Key or so,...
But I think it is not so important to secure if the email is under
controll of the keyowner. The worst thing that could happen is, that an
encrypted message isn't received by the (private)-key owner, because the
email is wrong. But this can even happen when the email is correct (e.g.
if someone controlls part of the network).
What it all comes down to is: In my opinion - and correct me if I'm
wrong - validating the email once does not make much sense. The only
good alternative is some service like PGP Global Directory Key.
What are the advantages of using C-only keys?
Uhm,.. inm y opinion the stanard intends using C-only keys, if not they
would have created only the S-flag, that stands for both, signing and
certification.
But they created the following flags:
0x01 - This key may be used to certify other keys.
0x02 - This key may be used to sign data.
0x04 - This key may be used to encrypt communications.
0x08 - This key may be used to encrypt storage.
0x10 - The private component of this key may have been split by a
secret-sharing mechanism.
0x80 - The private component of this key may be in the possession of more
than one person.
Isn't this really saying you want to use a C-only key because it is
possible to use it? I don't see you presenting a reason to use them
aside from "the standard has them, and since they exist in the
standard, clearly they're supposed to be used". Lots of things are
possible, but not necessarily useful. C-only keys are possible, but
not viable in the real world.
Please see my "weak" reason in the other email ;)
Note that it's also possible to make a CS Elgamal-E key. It's utterly
meaningless, but physically possible to create. Not every bit pattern
is useful.
Eh? I thought GPG wouldn't support signing with ElGamal as that is very
complex? There was an issue with such key, as far as I can remember,
wasn't it?
Another advantage is perhaps, that a C-only key shows other users that
the key is perhaps used in a more secure way (because it's not used for
signing plain data).
It doesn't say this.
(also: see other email)
You are right,.. it doesn't _prove_ it,.. but I think it indicates it.
Refer to my example with the DFN-PCA (other email).
They say: "We don't use our root ca key for signing plain data." Neither
a key flag (C-only) nor their policy could proof this. Someone who works
there could just take the key and sign his personal mp3 collection,...
nobody would ever know ;-)
You could make a CS key, sign some data, then
flip it to a C-only key. The other user can infer exactly nothing
about the past usage of a CS key compared to a C key.
Yes,.. as above,... a C-only flag proves nothing,... but indicates a
little bit,...
btw: If the key owner (who can change the flags as he like) is good,..
he'd upload the modified key to the servers,... the server would save
the selfsigs and other users could trace the changes to the usage flags,
right?
Ok,... I hope I can end that thread with the following:
-I think the developers are not going to introduce such a feature in the
next time, correct?
=> I'm not very familiar with the GPG code, but if a developer would
tell me that such a feature wouldn't be too difficult to implement, I'd
try to do it... (if I find the time,... have to write my diploma.... :-( )
Unfortunately, now one here could tell me an tool that let me change the
deep internals of OpenPGP keys (including key usage of course ;-) ) so I
tried to do it manually:
-As I told you in some other thread (think the backsig-thread) I've
already read most parts of rfc2440,.. and played a bit with some
testkeys and with gpgsplit and a hexeditor....
I've already managed to find the correct bits (for example for the usage
flags) for various things...
When I tried to change the usage flag it worked,.. but of course... gpg
complained due to the invalid signature...
So: When I change settings (shouldn't matter which ones) in my
selfsigs,.. how can I recreate the signaturedata itself?
And what is the right way to reassemble the parts that I receive from
gpgsplit? Simply a cat * > key ?
Best wishes and thanks in advance,
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
org:Munich University of Applied Sciences;Department of Mathematics and Computer Science
adr;quoted-printable;quoted-printable:;;Lothstra=C3=9Fe 34;M=C3=BCnchen;Freistaat Bayern;80335;Federal Republic of Germany
email;internet:[EMAIL PROTECTED]
tel;home:+49 89 24409568
tel;cell:+49 172 8617341
x-mozilla-html:TRUE
url:http://fhm.edu/
version:2.1
end:vcard
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
