I know that in a least one conversation with the TIS folks, header
size was explicitly stated as not a factor in choosing the right
approach. Barring comments to the contrary, let's assume this is the
case.
This is true. MIME handles all these issues.
> Also, the PEM WG notes point out that the requirements for
> originator and recipient key ids are different, and that might
> argue against adopting a uniform approach to selecting such
> ids, across the various "name forms" cited in the I-D,
> especially since the syntactic uniformity exists primarily at
> the top level and then diverges for various specific name
> forms.
I think allowing different originator and recipient forms is
reasonable and consistent with how the cryptography is actually
utilized.
I have yet to be convinced there is any significant advantage to this
approach. A user has a public/private pair. As to whether the public
component or the private component is employed is easily determined by
context, regardless of whether I'm an originator or a recipient.
Although it might be useful (although I'd like a specific example of
how) to indicate in the syntax what is already known by context, I fail
to see the benefit of the additional complexity in an implementation.
I would appreciate if someone would enlighten me.
Also Steve (Kent), I wonder what you think about Sandy Murphy's
comments on the TIS database implementation:
> We have eliminated the certificate orientation for the
> database as well as the hashing and lookups. We are making
> the public key itself the fundamental orientation of the
> database. We are also going to a flat ascii file with no
> hierarchy.
A while back, I suggested making the public key the fundamental
orientation and you pointed out that this is not a good idea
since such a database cannot be distributed. Based on TIS's
approach, it seems that a distributed database is not being kept
open as a design goal. I wonder what your view is on this,
Steve?
I, too, am interested in Steve's comments as I do not recall them.
However, even if it's true that a database oriented according to the
public key can not be distributed, I fail to see where this is a issue.
The database being discussed here is a local database used by local
application programs to support the PEM protocol. It is one of several
databases that might be employed by local application programs that need
the public/private keys of originators/recipients.
As you might expect, the public key is not the only index into the
database. It is simply the element required to be unique for each
"user" recorded in the database. I would assert, in fact, that of all
the elements that must be in the database for each user, it is the one
most likely (required, even) to be unique and, thus, no other element is
suitable for orienting the database.
Having said that, let me also say I wouldn't implement a distributed
databased keyed according to a public key, principally because there are
other elements that lend themselves more naturally (from a human
perspective) to hierarchies of distributed databases, in particular
distinguished names and email addresses.
Jim
binb88607Jq3L.bin
Description: application/signature