PGP bug? Does not recognize primary uid

[Jorgen Lysdal]

Robert J. Hansen wrote:
> Jorgen Lysdal wrote:
>> So any question on compatibility should be sent to the PGP forum? :)
> 
> No.  If you have a key created in PGP that's not working in GnuPG, by
> all means, ask here "hey, what's going on?"
> 
> If you have a key created in GnuPG that's not working in PGP, you should
> probably be asking there.
> 
> Or, generally speaking, ask the people who have detailed interior
> knowledge of the system which appears to not be working right.

I get what you are saying, my fault. However, to the answers you gave to
my question, the implementations does not really matter.

> No, it doesn't defeat the purpose of a primary UID.  Which UID is
> "primary" is strictly a matter for the convenience of human beings.
> OpenPGP doesn't draw that distinction.  It's totally irrelevant to the
> system.
> 
> The totality of the OpenPGP language on user IDs is such:
> 
> 
> 5.2.3.19.  Primary User ID
> 
>    (1 octet, Boolean)
> 
>    This is a flag in a User ID's self-signature that states whether this
>    User ID is the main User ID for this key.  It is reasonable for an
>    implementation to resolve ambiguities in preferences, etc. by
>    referring to the primary User ID.  If this flag is absent, its value
>    is zero.  If more than one User ID in a key is marked as primary, the
>    implementation may resolve the ambiguity in any way it sees fit, but
>    it is RECOMMENDED that priority be given to the User ID with the most
>    recent self-signature.
> 
>    When appearing on a self-signature on a User ID packet, this
>    subpacket applies only to User ID packets.  When appearing on a
>    self-signature on a User Attribute packet, this subpacket applies
>    only to User Attribute packets.  That is to say, there are two
>    different and independent "primaries" -- one for User IDs, and one
>    for User Attributes.
> 
> 
> ... There are a couple of other quick offhanded references (packet
> specifiers, one reference to how a symmetric algorithm may be chosen,
> etc.), but that's the meat of it.
> 
> There is no MUST anywhere in that paragraph.  Implementations are
> therefore free to do whatever they like with it, including ignore your
> preference and arbitrarily say "okay, we're going to treat this other
> one as your primary".
> 
> 

Got it! Thanks