Cryptography Reference
In-Depth Information
the existence of such a trusted entity is acceptable and practical. Note in
particular that:
• the TKC should be online , since it could be called upon at any time to establish
private keys;
• only the TKC can derive the private keys in the system, hence it provides a
source of key escrow, which can either be seen as desirable or undesirable (see
Section 10.5.5);
• the TKC requires secure channels with all private key owners, with the similar
advantages and disadvantages as discussed for trusted third-party generation
of key pairs in Section 11.2.2, except that the TKC cannot 'destroy' the private
keys as it always has the ability to generate them.
Nonetheless, there are many potential applications where the existence of
such a TKC is reasonable, especially in closed environments.
Revocation issues . One of the problems with tying a public-key value to an
identity is the impact of revocation of a public key, should this be required. If
the public key has to change, we are essentially requiring the owner's 'identity'
to change, which clearly might not be practical. An obvious solution to this is
to introduce a temporal element into the owner's 'identity', perhaps featuring
a time period for which the public key is valid. For example, Bob's public key
might become PubB3rdApril for any encrypted messages intended for Bob
on 3rd April, but change to PubB4thApril the next day. The cost of this is a
requirement for Bob to obtain a new private key for each new day.
Multiple applications . Another issue is that it is no longer immediately
obvious how to separate different applications. In conventional public-key
cryptography, one owner can possess different public keys for different
applications. By tying an identity to a public-key value, this is not immediately
possible. One solution is again to introduce variety into the encryption key
using, say, PubBBank as Bob's public key for his online banking application.
However, it should be pointed out that IDPKC offers a potential advantage in
this area since it is possible for the same public key PubB to be used across
multiple applications, so long as different system secrets s TKC are used to
generate different private keys.
It is important to recognise that these issues are different issues to those of
certificate-based public-key cryptography. This means that IDPKC presents an
interesting alternative to conventional public-key cryptography, which may suit
certain application environments better, but may not be suitable for others.
For example, IDPKC may be attractive for low-bandwidth applications because
there is no need to transfer public-key certificates, but will be unattractive for
any application that has no central point of trust that can play the role of
the TKC.
It is also important to realise that some of the challenges of certificate-based
public-key cryptography remain. One example is that the need to register for
Search WWH ::




Custom Search