Re: 2003 PKI Research Workshop CFP

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

>The Internet2 PKI Research activity is based on the premise that a
>great deal of research is needed in PK-authenticated authorization
>and control systems and that research is not going to come out of
>current efforts among PKI vendors and standards bodies, active though
>they may be.

Carl,
I could not agree more.   Although my perception is that many of
the problems can be concluded as follows.  At least if we are
talking e-commerce:

- The competence of implementers of e-business systems with
   respect to PKI is very low.

- The certificates issued by most CAs do not fit the needs
   of e-business[*].

- The close to religious belief that paper-signatures and
   e-signatures have to be identical in order to create a
   trustworthy PKI-enabled e-world.  As someone else
   recently noted in this list, a paper-signature is technically
   as different to a digital signature as "analog" is to "digital". 

*] So what is the #1 problem with current certificates?
Well,  business systems are "dumb" and cannot understand that
"CN=Jane Doe, O=ACME, C=US" and 
"CN=John Doe, O=ACME, C=US"
actually come from the same business party and could lead
to valid messages put in quarantine or even being rejected.

This problem does neither exist in the traditional EDI-world
(using partner IDs), nor in the paper-world (using letter-heads),
where names of individuals are just attributes (payload) that
only occasionally is of any importance to the receiver.

But some business systems manage by _tailoring_ the "receiver"
code for each CA.    I.e. in the case above by only using O and C.
If the receiver instead is deciphering a web-server certificate
the entire Subject string or just CN should be used (to get a stable
identity property string).

Some vendors, like VeriSign have introduced DUNS numbers
as a private _option_ which just makes things even worse.

Permanent identifiers added another [but standardized]
way of screwing up RP software by making DN interpretation
an option that the CA may or may not support.

Anyway, this leads to essentially zero interoperability
compared to using shared secrets, de-facto making "open"
PKI a joke as it is _technically__impossible_ to create shrink-
wrapped RP-software that will work on the level needed by
business software, that simply cannot rely on the availability
of local PKI-gurus for carrying out day-to-day operations.

Unfortunately it seems that few (any?) PKI researchers are
interested in bothering with "low-level" stuff like compatibility
with existing business systems and processes, as most PKI experts
think in terms of signed e-mail which is a trivial  problem as the
relying party is usually _human_ that can do all kinds of more or
less clever decisions regarding unknown CAs, names etc.

Computerized RPs are _several_magnitudes_ harder to support
as things in the digital world are either TRUE or FALSE.

==============================================
I hate to admit it, but as long as this problem stays un-addressed,
it is better to refrain to Lynn Wheeler's relying-party-only PKI.
Or do as I propose: Only use web-server certificates from leading
commercial CAs, for inter-organization-messages as these are the
only certificates that are globally trusted, feature globally unique
static identifiers (in the CN), and are both easy and affordable to buy.
==============================================

Anders