PGP bug? Does not recognize primary uid

Jorgen Lysdal j.lysdal at
Mon Jun 16 17:51:42 CEST 2008

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:
>  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

More information about the Gnupg-users mailing list