[Standards-JIG] The Great Encryption Debate
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