[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth -Reply
Robert R. Jueneman
Software Engineering Consultant
NetWare Security R&D
Internet Infrastructure Division
Novell, Inc. M/S-PRV-D241
122 East 1700 South
Provo, UT 84606
801/861-7387
>>> David P. Kemp <dpkemp@missi.ncsc.mil> 06/20/96 07:29am >>>
Date: Wed, 19 Jun 1996 18:10:24 -0500 (CDT)
From: "Brian M. Thomas" <bt0008@entropy.sbc.com>
>> (3) verification of the uniqueness of keying material shall be guaranteed
>> during each naming attestation by each and every principal in the domain
>
> Perhaps you could explain why this should be so.
>It would be unfortunate if two totally unrelated users shared, by chance, the same keying material. It would be more unfortunate if one
or the other of them discovered this fact.
Yes, it certainly would!
>A hierarchical certificate creation mechanism can ensure that keying material is not duplicated anywhere within the hierarchy; an
uncoordinated mechanism can make only probabilistic "guarantees".
I don't think I follow you. The certificate creation process is not necessarily tied to the key generation process, and at least in most of
the implementations I am aware of the user generates the keys herself, then brings them to the CA for signing. As a result, there is little
or nothing standing in someone's way if they want to use the same key pair for both PGP and an X.509-style certificate, or two X.509
certificates containing different names or roles, etc.
The only way that I know of to prevent reuse of keys, both across users and optionally across time, is to construct a global database of
keys, and check each key upon certificate creation. That might be a good function for a repository, I suppose, but I haven't heard of
anyone planning to perform such an operation. If the database is not global, but instead limited to a given hierarchy, then you still have
the problem of possible collisions, either accidental or deliberate.
>This may be good enough for the commercial "insurance" business model, but it doesn't give me warm fuzzies.
>This is not really related to naming, except that "naming attestation" as used above appears to be a fancy term for creating a certificate
- generating a keypair and assigning a name. The generation of key is what counts, the name is irrelevant.