(V3.1.1)
	id xma004128; Thu, 15 Aug 96 16:02:20 -0400
Received: from dustin.verisign.com (gateway-outside [204.162.64.20]) by
rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id NAA26488 for
<pem-dev@tis.com>; Thu, 15 Aug 1996 13:04:17 -0700 (PDT)
Received: from Peter.verisign.com (Peter.verisign.com [192.42.157.77]) by
dustin.verisign.com (8.7.4/8.6.12) with SMTP id NAA21769 for
<pem-dev@tis.com>; Thu, 15 Aug 1996 13:04:15 -0700 (PDT)
Received: by Peter.verisign.com with Microsoft Mail
	id <01BB8AA2.D9270A10@Peter.verisign.com>; Thu, 15 Aug 1996 12:11:11 -0700
Message-Id: <01BB8AA2.D9270A10@Peter.verisign.com>
From: Peter Williams <peter@verisign.com>
To: "'pem-dev@tis.com'" <pem-dev@TIS.COM>
Subject: Forrester report
Date: Thu, 15 Aug 1996 12:11:06 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk

One might wish to consult on the web the Forrester report, volume 1, number 11.
It focuses on the commercial deployment of the PKI pem-dev has been discussing
to years.

One interesting point: it notes in a paragraph titled "Interoperability will be
muddled by limited standards" that "X.509 v3 includes the ability to add custom
fields that always hamper interoperability". (It then has an incompetent
statement about DSS and X.509.)

How quaint. Vendors scream for flexiblity, std extensions are defined, then
the mere
possibility of further flexibility is decried. Perhaps standards wisdom is
available
to help this war weary programmer!

Another interesting point, forseen by PEM designers, is that obviously hihger
level authoriites need to exist to "represent" the trust and
algoirhtm/keying properties
of the domain. I.E. PEM PCAs. 

However, it denotes such a function as a "rating service", versus an integral
part of the trust enviornment as with PEM PCAs. Whilst I dont believe the
rather's liabilities are solved by such a transition, the notion is perhaps
indeed
viable as a refinement of what PCAs really were.

Finally, the report notes that risk management requires that various levels
of "identity confirmation" (what the X.800 std terms "authentication
management") 
will be required.

This is slightly humerous to as many in our industry claim that only a single
a uniform (high) level is tenable to all financial and other user
risks. Didnt PEM start out with this notion too, and learn to drop it!?

Its nice to see 1422 coming of age within only minor cosmetic changes. We
just have to teach folk now the difference between residential and
organizational
telematic service delivery, and we'll be there!

Peter.




--
John C. Kelley
System Administrator                            (301) 854-6889
Trusted Information Systems, Inc.               (301) 854-5363 FAX
3060 Washington Road                            johnk@tis.com (work)
Glenwood, MD  21738                             johnk@radix.net (play)