keyflag subpacket and key expiration subpacket

[Christoph Anton Mitterer]

>>So does this mean if a key would have its key-exp-time/key-flags on an 
>>0x1F that gpg would understand this?
>>    
>>
>Yes.
>  
>
Ah, great, so gpg is compliant to the standard in that point.
I think only
key expiration time (9),
revokation key (12),
notation data (20) (in those cases where the data applies to the key 
itself and not to a specific UID),
key flags (27) and
reasons for revokation (29)
should go there.....

Would it be easily possible with gpg to put those subpackets (currently 
I'd only need it with 9 and 27) in a 0x1F sig? If so could you please 
give me a hint to some function(s) in the code that I'd have to parse 
and modify for my personal needs (as with the key flags when I wanted to 
change it to C-only ;-) ). (Yes I'm still trying to create the - in my 
opinion - perfect OpenPGP key ;-) )


>>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 don't agree that the standard requires this, but even if it did, the
>IETF "be conservative in what you generate, liberal in what you
>accept" meta-rule applies.
>
Well that's always a problem.... but therfore we have standards, I think.

- First of all: I didn't say that gpg (or another implementation) MUST 
put it in an 0x1F.

- I quick-parsed section 5.2 of the RFC an it says nowhere that an 
conforming application would be allowed to not-implement any of the 
given sig-types.

- It even says that an application MUST understand (but not necessarily 
generate) v4 sigs; this follows from "Implementations SHOULD accept V3 
signatures. Implementations SHOULD generate V4 signatures.", I  think.

- In 5.2.3.1 it says that an "implementation SHOULD ignore any subpacket 
of a type that it does not recognize" (except the "critical" bit is set) 
BUT it says nowhere that an implementation understand a subpacket type 
in on sig type but not in another....

This is why I came to the idea that in my opinion the standard requires 
to understand this (of course: only if an implementation understands it 
in other sig-types (i.e. 0x13), too)


btw: does gpg fully support the critical bit an can I somehow set it (if 
so, please point me to specific functions, too; if possible)?
I'd like to do this for my:
- signature expiration time (3) (which requires a critical bit for 
signature creation time (2), too)
- exportable certification (4)
- key expiration time (9)
- key flags (27)
subpackets, because I think those are really security relevant if an 
application wouldn't be able to understand them. The other subpackets 
are not so relevant, I think, because they couldn't create a security 
hole if an application wouldn't understand them (e.g. if the trust 
package isn't understood, other keys wouldn't be taken as valid => ok, 
not so nice, but not a security problem BUT if an application doesn't 
understand the 0x3 subpacket it wouldn't notice if the signature is 
already invalid).

>Where is the benefit in using 0x1F and not being able to communicate with others?
>  
>
- Well I think thats why there is a standard: To strictly specify how 
implementations from different vendors can interoperate together. If a 
vendor (e.g. PGP Corp.) would not comply with the rules, he'd break 
interoperability, but I think just because a vendor has many users, no 
other vendor should break the standard, too.
gpg doesn't do that, as you said it fully supports 0x1F sigs.


- The same thing applies (in my opinion) to the compliance options that 
gpg supports,... I think the reason for their existance are that there 
are a older applications (e.g. PGP 2.6.x) and especillay older keys (and 
most users would like to continue using their existing keys).
Of course that's a good thing, ...

But: Are there really those many users of OLD implementations?
And for the old keys: Is it really cleaver to strongly support those 
users in continue using their old keys? I think with v3 keys there is 
that key-id-forging issue,... and the old v3 sigs use MD5 only, jesus! 
It wouldn't be that bad (I think) to offend sensibilities of those users 
and "force" them to create new keys...

Thanks and best wishes,
Chris.

btw: is there a policy for the gpg list? Should the author whom I reply 
to be CC'ed?
-------------- 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/09807a99/cam.vcf