Subject: Resolving multiple primary user IDs and self-signatures

From: David Shaw <[email-masked]>
Date: Fri, 24 Aug 2001 13:56:32 -0400

Here are two suggestions to help with resolving multiple user IDs
marked primary, as well as resolving multiple self-signatures with
different subpackets:

From 5.2.3.19. Primary user id:

   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.

From 5.2.3.3. Notes on Self-Signatures:

   Since a self-signatures contain important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as preferences
   and key expiration.
|  An implementation that encounters multiple self-signatures on the
|  same object may resolve the ambiguity in any way it sees fit, but
|  it is RECOMMENDED that priority be given to the most recent
|  self-signature.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Florian Weimer <[email-masked]>
Date: 25 Aug 2001 13:11:52 +0200

> marked primary, as well as resolving multiple self-signatures with

This should probably go into a separate RFC.  Currently, RFC 2440 and
RFC 2440bis deal only with syntactic issues (apart from a minor glitch
in RFC 2440bis, 'A revoked certification no longer is a part of
validity calculations.').

On the other hand, If such additions are accepted, I've got a long
list of them...

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: David Shaw <[email-masked]>
Date: Sat, 25 Aug 2001 10:44:36 -0400

> validity calculations.').

True, and it even says that in the Abstract.  There is an exception
made for security issues: "It does not deal with storage and
implementation questions.  It does, however, discuss implementation
issues necessary to avoid security flaws."

Offhand, I can't think of a security implication to having multiple
UIDs marked primary (though I'm sure someone here can).  My concern is
with the security implications of having multiple conflicting
self-signatures.  Without some suggested way to resolve the conflict,
there can be security implications.  If it is truly a security issue,
then it is appropriate in 2440bis.  (Obviously, I think it's enough of
a security issue to mention - I'd like to hear what others think.)

Self-signatures can carry subpackets that definitely affect the
actions that may be taken with a key.  To use one of my examples from
last night, if/when a symmetric cipher or hash is broken, the user can
simply announce that cipher or hash is not accepted (via a "preferred
symmetric algorithms" or "preferred hash algorithms" subpacket).
Without a way to resolve which self-signature is the one to follow,
the broken cipher or hash may be used, which could compromise the
security of the message.

> On the other hand, If such additions are accepted, I've got a long

Care to work on a "Implementation Suggestions for OpenPGP" with me?

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

---

From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 15:36:52 +0200

[RFC 2440 et al. as mere syntax]

> issues necessary to avoid security flaws."

I think it limits itself to security flaws which directly break the
cryptographic algorithms involved.  Flaws at a higher level are not
discussed.

> a security issue to mention - I'd like to hear what others think.)

Differences in interpretation of expiration times can have security
implications, too. ;-)

> Care to work on a "Implementation Suggestions for OpenPGP" with me?

Yes, details will follow in private mail.