keyflag subpacket and key expiration subpacket

[Christoph Anton Mitterer]

David Shaw wrote:

>It's tradition and history.  GnuPG will accept subpackets on either
>the 0x13 (0x10, 0x11, 0x12) or 0x1F, of course, but only generates the
>0x13.
>
So does this mean if a key would have its key-exp-time/key-flags on an 
0x1F that gpg would understand this?
All the other subpackets, that don't refer to a signature itself (like 
creation/expiration time of the sig/exportability), preferred algos and 
even things like the features subpacket would make sense on a 0x10-0x13 
selfsig indeed.


>If we switched over to 0x1F, we'd probably break compatibility
>with other OpenPGP implementations.
>  
>
Well these applications are not really implementations of OpenPGP. The 
standard clearly specifies which parts an implementation must not 
implement. And as far as I can see implementations are allowed to don't 
implement subpackets (but in that case they must consider these packets 
if the critical bit is set) but they aren't allowed to recognize 
subpackets only on specifiv sig-types (expect those where the standard 
itself allows a subpacket type only on special sig-types).


>I agree, though, that things like key expiration would really make
>more sense on a 0x1F sig.
>  
>
Yes,.. as an intermediate improvement, gpg could create the subpackets 
(key-exp and key flags) on a primary-flagged sig only.

>>btw: in keyid.c there's the method usagestr_from_pk() is it a bug that 
>>only keys that have the S-flag can have a C-flag, too?
>>    
>>
>I assume you're looking at 1.4.2.  No, it's not a bug because in 1.4.2
>there is only one internal flag (PUBKEY_USAGE_SIG) for both sign and
>certify.  The extra check for a primary key is just so the "C" flag is
>set in the display string.
>
>It's different in 1.4.3, by the way, where PUBKEY_USAGE_CERT is used
>in addition to PUBKEY_USAGE_SIG.  None of this is visible from the
>outside though.
>  
>
Ahh, ooops,.. you're right :-) .


Best wishes,
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/20051216/07fa4595/cam.vcf