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]