JeffT>Let me ask the following question: Why have an
Originator-ID-Asymmetric field at all when an Originator-Certificate
works just fine? Why was it put in the standard? It is an
implementor's nightmare.
Bob J>I think the assumption was that it was desirable to cut down on
all of the clutter that results from including all of this information
in the message every time.
Steve D>Since the Originator-ID-Asymmetric lists the Issuer Name and
Serial number of the sender's certificate, a recipient who didn't have
the sender's certificate would only have the certificate Issuer Name as
a starting point for a certificate lookup.
The last time I asked a similar question, I was told that it was up to
the receiver to get that data from the sender if it was not locally
held. When I asked Burt (as the author of RFC1424) about the message I
should use to request the information, I was told that the message had
not been thought of before then, and that, anyway, it properly was a
part of RFC1421, not 1424. Be that as it may, no one wants to take on
the job of completing the system design for PEM, which as Jeff has
pointed out, is an implementor's nightmare. -- I am reminded of a
cartoon on one of my engineer's walls that shows a Boss (me I presume)
dropping off a single sheet of paper to a programmer saying "Here, get
started on the programming, I will see if I can find the
specifications." I will try to get a copy of it for Jeff.
- -
P.Williams>If you use a racing car on a back road, you'll quickly break
its suspension, and get stop getting where you want to go. Perhaps you
choose a lower grade race, in which the system requirements are less
stringent, and implementation is easier.
PEM isn't a race car. It's a prototype. There are no race tracks.
There isn't even a superhighway (but Al's workin' on that one). The
current inet is the equal of the mud tracks that horse and buggy used
before cars were allowed to go over 12 miles/hour.
Peace