pem-dev
[Top] [All Lists]

key selectors - what more can we say

1995-01-02 15:03:00
I believe it is time to kill off this discussion of key selectors, name
forms, and identifiers.  As far as I can tell we haven't added anything
to the discussion in the recent past.  Therefore, I believe the right
thing to do is to leave the specification as it currently exists.

In support of leaving the specification as proposed, let me restate the
following *FACTS* that have been presented on this mailing list.

1. public key is sufficient but unsuitable by itself

   Jeff Thomson has been the principal advocate of just using the public
   key.  While I agree it is sufficient for the purposes of supporting
   the PEM services, it is insufficient for supporting PEM-based
   applications.  Warwick Ford provided the ideal example of why this is
   so: the public key is an insufficient general database index.
   Although it may very well be useful in small or closed communities,
   it just does not scale.  Having a name form provides a generic index
   into a database that makes additional information available to an
   application, for example the CRL for a certificate.

2. hash of public key unsuitable

   Similarly to the public key, the hash of the public key (or any
   value) is sufficient and unsuitable for the same reasons.  It is also
   unsuitable because it introduces two additional interoperability
   points of failure: the choice of hash algorithm and the choice of
   encoding for the value to be hashed.

In support of the specification as written, let me state:

1. the name forms provide a generic mechanism for looking up additional
   information in a database, not just a public key

2. an arbitrary key selector that is treated opaquely by an
   implementation introduces no additional complexity in that
   implementation.  (As an implementor I can state this as a fact.)

If I have misstated a fact or have forgotten a fact, please reply to
this message and let us all know.  Otherwise, I think we are done.

Thanks,

Jim

<Prev in Thread] Current Thread [Next in Thread>
  • key selectors - what more can we say, James M Galvin <=