>From: Steve Dusse <spock(_at_)com(_dot_)rsa>
>Subject: Originator-ID-Asymmetric and X.500
>Date: Mon, 14 Mar 94 09:24:47 PST
PEM is message handling protocol. The semantics of the protocol
used outside a messaging application context are ambiguous.
All the cited Originator-ID-Asymmetric field problems mentioned so far
have assumed a contrary position - that PEM can be processed
independently of the environment in which is was designed to be used,
and to provide a different service from that which it protocol elements
are designed to support.
If you use a racing car on a back road, youll quickly break
its suspension, and get stop getting where you want to go.
Perhaps you should choose a different car design for track driving.
>This would appear to be a major roadblock in using X.500 to serve PEM
>certificates.
NO. Only when processing is occurring without the full support of each
of the required applications service elements.
If you put the wrong tires on the cars for the road conditions, you
lose the race. If you take out the temperature regulator,
you will overheat... and stop.
Perhaps you choose a lower grade race, in which the system requirements
are less stringent, and implementation is easier.
>Perhaps the Originator identification mechanism should be even more
>flexible to accomodate other more "local" means of identifying a
>sender to a recipient (like email address or something).
Yes. Both Carl and RSA (RIPEM) should specify this. but
dont break what is already there...
Then we will have a multi-functional car. Currently with RIPEM,
my PEM service station cant do anything, as RIPEM uses parts I dont stock,
and are not even in the catalogue. This is particularly annoying as it uses
the PEM trademark headers to announce itself (fraudulently).
(Munich, 1986/1987 IFIP 6.5. Einar Stefferud reduced a (stroppy) Xerox
intern to stuttering, for daring to propose a distributed header field
which "nobody" else could process, and which were vital to the funcioning
of the information processing.)