James A. Donald wrote:
In an organization with hundreds of administrators
managing tens of thousand of machines, what goes wrong
with trusting your key store?  And who administers
Kerberos?  Don't they have a problem with tens of
thousands of machines?

the original pk-init draft for kerberos just had public keys being registered in lieu of passwords ... in much the same way that people register public keys as part of the "registration authority" part of a pki certification authority process.

machines then could have public keys to authenticate communicating with the trusted public key store (imagine it like real-time access to a certification authority ... in lieu of the stale, static digital certificates). to the extent that such machines can trust a repository of trusted certification authority public keys ... then they could also have a trusted repository of public keys for real-time communication with key store (where a key store might also be replicated for availability and scaling ... in manner analogous to the way DNS had replicated trusted servers).

it was only later that the draft succumbed to the pressure to also allow
PKI digital certificate mode of operation ... i.e. the machines rather than doing real-time authenticated communication with the trusted key store ... they might also use a local trusted public key repository to authentication certification authority digital signatures on stale, static digital certificates.

basically the key registration process is identical in the PKI digital certificate mode of operation and the certificateless public key mode of operation. the management of the trusted public key repository (of trusted "root keys ... in one case for certification authorities, in the other case for the key store) on each machine is effectively also identical. however, the certificateless public key mode uses real-time communication with the key store ... while the PKI digital certificate mode substitutes the whole digital certificate issuing, management, administrative, etc infrastructure overhead (in lieu of the much simpler real time communication).

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to