MEMORANDUM

TO:     Jim Clancy
FROM:   Keith Corbett
DATE:   23-Jul-87
SUBJ:   PICON Tracking/Encryption Scheme
COPY:   Bill O'Brien

George's proposal (21-Jul-87) is a great improvement over the encryption
scheme used in PICON 1.x.  However, I do have some concerns and
questions.

A few months ago George told me that the new PICON security scheme would
not involve encryption or validation. He was going to make custom tapes
with the customer name hidden in the object code, and provide a banner
in the PICON window that clearly identified the customer for whom the
tape was made.  The disadvantage of having to make custom tapes was a
tradeoff against the advantage of eliminating the support burden caused
by encryption.

I agreed to do front-line support for PICON with that understanding. I
don't want to pursue that arrangement unless the following objections
are addressed to our mutual satisfaction:

1. With this method, each tape must be made separately. This could lead
to each customer having the latest, "greatest," version -- no
standardization.  I'm sure that's not the intention, but it has happened
in the past, and made support more difficult.

It would be better for the company as a whole if the PICON group would
produce a standard release, with documentation, BOM's in the Inventory
system, etc.  But this requires a standard tape that can be sent from up
here.  Without that, the PICON group must do all the tracking, shipping,
etc.  on its own.  [Once again, PICON goes its own way, separate from
the rest of the company...]

2. The LICENSE-IDENTIFICATION.LISP file feature implies that the
authorization would only be needed once.  This is a definite
improvement.  However, the procedure, and implications, must be clearly
documented to be useable by the customer; but it must be documented
without revealing the details, or customers could defeat the security
(i.e., copy the tape and make a copy of the license id file.)

3. I don't like the idea of using SITE-NAME, HOST-NAME, CHAOS and/or
INTERNET addresses in the encryption.  Our customers -- PICON users,
especially -- already have enough site-file-related problems.

The expiration-date encryption is a good idea; it could be used more
widely as a non-volatile limited-time licensing protection. Even though
it's easily defeated, the act of doing so (by setting the system time
back) is very visible to customers, LMI service personnel, etc.


KMC