Keytypes and changing them

[Christoph Anton Mitterer]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cam.vcf
Type: text/x-vcard
Size: 449 bytes
Desc: not available
Url : /pipermail/attachments/20051129/6df14c38/cam.vcf