Subject: RE: Proxy PKI. Was: IBM alternative to PKI?

From: Trevor Perrin <[email-masked]>
Date: Fri, 17 May 2002 11:14:47 -0700

Hi Lynn,

I agree that using a password<->PKI middleman doesn't provide end-to-end PKI
trust.  But it could provide end-to-end trust, in the sense that, when the
middleman signs, he explicitly mentions the name being signed for, or when
something is encrypted to the middleman, it explicitly includes the name the
encrypted data is intended for.

Such a middleman would be a replacement for an identity certificate/key
pair, but it would not "artifically fabricate" signatures by holding
multiple keys, one for each client, but would instead make honest statements
such as "I authenticated Alice with a password, and am signing this on her
behalf".

The point, I guess, is that you can have end-to-end security (meaning
authenticated or confidential communications with end-users) without
end-to-end PKI, if you trust the PKI endpoints to make authentic statements
from, or deliver confidential statements to, end-users..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 17, 2002 4:03 AM
To: Anders Rundgren
Cc: Dean Adams; [email-masked];
[email-masked]
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?

you can do server-based PKI in conjunction with multiple authorization
operations .... i.e. somebody uses a password to talk to a server-based PKI
... and the server turns a password operation into a PKI operation at the
same time doing other organizational functions. However, it would be a
mistake to assume that because two different operations are being performed
by the same server ... that one kind of operation (password to PKI
translation) also inherits the other kind of operation (say multiple
approval level operations).

The counter example is an end-to-end security implementation where the
original client signs the transactions ... and if there are multiple
approvals required because of business reasons ... that the other agents
(human or software) along the way also sign the same transaction ...
providing end-to-end security for both the original transaction as well as
any intermediate approval steps.

If a organization has both a requirement for multiple level approval and
can't deploy real PKI out to the end clients ... that they could implement
both business functions in a single data processing unit.

Various scenarios for end-to-end security and multiple levels of
approval/signing are

1) in the NR thread in this list, I made reference to the EU FINREAD
standard for token acceptor device having secure display and secure
pin-entry ... as part of trying to close some of the NR-service gap with
respect to human intention .... i.e. all operations requiring some
indication of human intention in support of any NR ... required that every
signed transaction need to have been done with a hardware token in
conjunction with a FINREAD terminal configured such that every transaction
signing first required a person to first enter a PIN. Provisions were made
in the x9.59 standard that not only would the originating client sign the
financial transaction ... but the "environment" that the signing took place
in would also sign the operation (i.e. not only could you claim that an EU
FINREAD certified device was used for the signing environment ... but you
could proove that an EU FINREAD certified device was used for the signing
environment .... because the certified device also signed the transaction).

2) various kinds of workflow systems ... may require two or more levels for
final approval for purchase orders. The purchase order business protocol
can have that external business entities don't have to actually
authenticate the lower-level or originating digital signatures .... but
just the final approval agent that is responsible for interfacing to
external organizations. However, it can be useful to carry the originating
and intermediate digital signatures along with the transaction as an
internal audit trail.

Now it would be possible to implement such a function where all the
internal corporate processes were password based and that only purchase
orders (or other types of transactions) that actually left the corporate
boundaries carried a digital signature .... in effect the digital signature
of the final approval agent. I would claim that any use of a unique
signature per originating employee ... rather than the digital signature of
the approval function (human or software) is an artificial fabrication. In
this particular scenario, the trust is between all the external business
processes and the unit performing the signing ... any use of unique
signatures per originating employee rather than a single signature of the
signing authority is an artificial fabrication. The only purpose of such an
artificial fabrication might be because we want to pretend that the trust
relationship is directly between the external units and the individual
employee (because there is a transition plan that employees will be able to
directly sign individual transactions and send them directly to external
agencies w/o any individual approval authority). Otherwise the artificial
fabrication is merely obfuscation ... internal audit procedures will be
able to tie individual password transactions to specific approval
transactions; each PO has unique identifier and audit trail of all steps
including relating to the originating employee and their password
transaction.

===============================================================

Bifurcating the end-to-end trust relationship with some passwords and some
PKI ... implies that there is different levels of trust between the
password-based trust relationship and the PKI-based trust relationship. The
bifurcation is either because 1) we are planning on transitioning to a real
end-to-end PKI relationship .... in which case we create the artificial
appearance of each originator signing with a unique key as an aid to that
transition or 2) there isn't any "real" end-to-end trust relationship ever
required, that the trust infrastructure really is partitioned ....  that
password is sufficient for "internal" operation and only the interface
agent is ever going to be signing, in which case only a single key is
needed by that interface agent. Since there is never going to be any real
end-to-end trust relationship ... the signing agent only needs a single
key. Having the server/signing agent sign with a different unique key per
originator is an artificial fabrication since there is actually no
end-to-end trust (or planned to be).

My original statement is that the server-based PKI is either an a) aid to
transition to individual key signing ... in which case there is a point of
creating the fabrication that there is some end-to-end trust or b) a
permanent solution ... if it is a permanent solution there is no real point
in creating the artificial fabrication of an end-to-end trust relationship
(with different key per originator) ... the trust relationship is between
the signing agent and the external agencies ... for the purposes of trust
... it is only sufficient that the signing agent sign the operation because
it would be a total fabrication that there is an end-to-end PKI trust
relationship between the external entities and the individual. A properly
designed business process designed PKI-trust operation would have the keys
belonging to the operational entities being trusted. Any implication that
the PKI-trust boundaries are different (i.e. server signing agent using
individual associated signing keys) is an artificial fabrication that would
need some valid business justification ... like the planned transition to
real end-to-end PKI-trust boundaries. If there is never going to be any
real end-to-end PKI trust relationship ... and the trust relationship is
only between the signing agent and the external entities then I would claim
that multiple different keys (one per originating employee) is superfluous.

There is also always the danger when creating artificial fabrications that
somebody might incorrectly believe there is a real end-to-end PKI trust
relationship that doesn't really exist. Business executives will typically
sign-off a risk acceptance when creating artificial fabrication when it is
shown that it is a temporary solution pending transition to real
implementation.

[email-masked] on 5/17/2002 3:31 am wrote:

Lynn,

That was a rather prejudiced description of  server-based PKI.

There must be a reason why 42M people use Internet-banks just in
Europe.  These banks serve as giant "proxies" and I don't see how
Internet-banks could ever be replaced by client-side PKI solutions!
Do you?

I.e. the use of a "middle-man" or "proxy" has other qualities than
just enabling PKI-transition/roll-out.

Another example are B2B-systems, where clients must perform
actions *through* the local business system which enforces the
authorization and policy rules.  In addition to storing in- and out-
going business-messages.  A structure that is in daily use since at
least 20 years back or more, so it is definitely time-proven.

And what's more, employees' privacy is protected by this arrangement.

By using server-PKI, companies and banks can abandon expensive
leased-lines and use the Internet.  Probably with an increase in security
compared to today.  Message integrity control is essentially for free
using PKI.

Server-PKI actually supports end-to-end security as well, although
there are two pair of end-points: client-to-proxy, proxy-to-rp.
When/If client-side PKI becomes ubiquitous, it just makes the link
between the proxy and client stronger.  Including NR support in case
the proxy want to sue the client for malpractice.  Or the reverse BTW.

I think the real discussion is really what constitutes an "end-point".
In B2B it does not have to be an individual as an individual is not
a company.   Few PKI-lawyers understand this as companies cannot
"sign" in the paper-world.  But in the "e-world" that's a piece of cake!

In case you want to try a B2B-system implementing server-based PKI,
using XML-Signatures for all B2B-communication, you are invited
to try out https://buyer.x-obi.com/BuyerASP/buyer
Properly written, and protected by firewalls, HW-crypto, and secured
physical facilities, such systems can work wonders.  As Internet-banks
already do, and that on a massive scale.

The only "business" that so far has not fully grasped the usefulness
of using server-PKI is the public sector, but I stay confident that
they soon will, as running a government authority should be rather
similar to running a company.  I.e. there are internal and external
communication, policies etc. that means that you must have a
"proxy" somewhere in your organization to maintain this in a
reasonable way.  The net effect is the external communication
will be performed by the proxy rather than by the employees.

Cheers,
Anders

---

From: Stephen Kent <[email-masked]>
Date: Fri, 17 May 2002 14:32:26 -0400

>from, or deliver confidential statements to, end-users..

Trevor,

This is not how the phrase "end-to-end security" is used in the 
literature, and thus I would suggest one not use the phrase to refer 
to any scheme in which an intermediary in the communication path must 
be trusted to preserve the security services being advertised. Terms 
such as "link security" and "hop-by-hop security" have been used in 
the past to describe analogous schemes.

Steve