[Standards-JIG] The Great Encryption Debate

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Fri Aug 19 22:49:25 UTC 2005

On Friday 19 August 2005 05:43 am, Ian Paterson wrote:
> Either way Bob has to do the work of verifying the WoT key and verifying
> something signed with the WoT key. In case b), Bob also has to verify
> something signed with the X.509, Alice has the extra work of creating an
> X.509, and all parts of the system have the extra work of distributing
> two keys.

If Alice and Bob want to use their WoT keys with an X.509-based protocol, then 
both will have to deal with WoT and X.509 responsibilities.  That is 
unavoidable.  However, you bring up an interesting point here:

> If for some reason Bob really wants an X.509 with Alice's public (RSA)
> key, then he can create it and sign the cert himself (instead of Alice
> creating it). In that case, the system is still saved the work of
> distributing two keys.

I had forgotten that, with X.509, a certificate need not include a signature 
from the owner at all.  Bob could easily create a certificate around Alice's 
key without her help.  This doesn't spare anyone from creating certificates 
(if Bob didn't do it, then Alice would have to), but it could save the need 
to transmit a second key.

But there are some problems:

1) If Alice's key is a PGP key, then it is not easily transferred into X.509 
format.  For example, if the PGP key is based on ElGamal instead of RSA 
(which is pretty much how all GnuPG keys are).  Additionally, since PGP 
services installed on the host system perform crypto operations as a black 
box, I don't know if developers can reasonably be expected to have access to 
the raw key.

2) I'm not certain, but if Bob has Alice's raw key (either extracted from 
another key format, or provided as-is in SubjectPublicKey), there could be 
some inconsistencies between the certificate that Bob creates based on this 
key (local to himself) and the certificate that Alice creates to use in the 
eventual X.509-based operation.  If necessary, we could probably come up with 
a scheme whereby both sides follow a set of rules in order to generate 
certificates with identical attributes.  However, since the signatures will 
surely be different, this might be a fruitless effort.  Again, I'm not 
certain what impact non-identical certs would have in a typical X.509-based 

By having Alice create her own X.509 certificate for Bob to use, these 
problems are solved.


More information about the Standards mailing list