[Standards-JIG] UPDATED: JEP-0027 (Current Jabber OpenPGP Usa ge)

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Mar 18 00:23:47 UTC 2004

On Wednesday 17 March 2004 1:27 pm, Justin Karneges wrote:
> On Wednesday 17 March 2004 6:32 am, Jacek Konieczny wrote:
> > On Wed, Mar 17, 2004 at 02:35:52AM -0800, Justin Karneges wrote:
> > > However, if one key in a keyring has a prefixed JID and another key
> > > does not, should the client simply go with the prefixed key, or should
> > > it prompt the user to choose between the two matches?
> > >
> > > I think if most people don't use the prefix, then the attacker could
> > > prefix his spoofed JID to gain priority and bypass any user prompting.
> >
> > User should be warned if untrusted key is used for signature
> > verification or encryption. If both keys are trusted one of them could
> > be prefered and choosen without asking the user. If the key to be used
> > is untrusted, then the user has to be asked about it anyway.
> Is it possible for the key user-id fields to slip past the view of the pgp
> user, if the key is already trusted?  For instance, what if the key
> validates via the web-of-trust, or if the user has already explicitly
> signed the key earlier and now blindly accepts updates?
> If the user must hand check every key that goes into his keyring, even
> updated keys, then there is no problem.

Ok, further outside discussion has led me to conclude that this is a PGP 
implementation issue, not something we should concern ourselves with.  The 
same "upgrade" attack could happen with X.509 as well, if the Certificate 
Authority does not fully ensure all fields are legit before signing the key.  
Therefore, a good PGP application would allow the user to inspect all keys, 
even those that are just updates of previous ones, before marking them as 

So looking for a prefixed JID first, with fallback to non-prefixed JID sounds 
acceptable to me.  The question is, which prefix to use?  Jacek, is there a 
reason you did not suggest using "im:" ?


More information about the Standards mailing list