pem-dev
[Top] [All Lists]

Re: altercation compromise

1995-01-05 13:45:00
        As many of the particpants in this debate are the same as the
        speakers or panelists in that symposium, could we perhaps
        suspend the argument or decision till then (allowing all works
        or positions to refine themselves based on the last 4 weeks of
        comment in the interim)?

What argument or decision?  After catching up on mail and sending the
messages I've just sent, I will repeat again what I said previously in
the message I've enclosed below.

Is there something new to say?  I have yet to see something new said
with respect to the PEM/MIME document.  I've asserted a position below
that is still valid as far as I can tell.

Jim
--- Begin Message ---
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

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>