PGP bug? Does not recognize primary uid

[Robert J. Hansen]

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.

> Interesting. I assume there is a good reason for this? I mean, does it
> not defeat the purpose of primary uid´s if they are not recognized
> between different software?

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".