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

From: [email-masked]
Date: Fri, 17 May 2002 05:02:53 -0600

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: [email-masked]
Date: Fri, 17 May 2002 06:17:00 -0600

note that i believe all the original ipsec stuff was end-to-end ....
lightweight ipsec i believe was introduced with VPN at a router working
group at the fall '94 IETF meeting in San Jose (by somebody who had
originally built one for thier personal use).

VPNs have some of the characteristics you claim for proxy PKI ... but they
don't claim to be signing stuff on behalf of other entities  ... they have
a specific trust model and the PKI mirrors the trust model of the units
involved in the trust operations. There is no artificial fabrication that
the VPN unit that does the signing as part of a PKI trust operation is some
totally other entity pretending to fabricate some totally different trust
operation.

VPNs also allow corporations to replace expensive leased lines with
internet connections.

bank-to-bank financial transfers don't happen under the pretend signatures
of the individual account holders. bank settlement has uthentication
between the two bank entities (either implicit, possibly because of leased
line, routing code, etc ... or explicit ... the banks actual authentication
process). As part of a bank-to-bank transfer ... banks will include adenda
records that break out the individual accounting detail.

---

From: [email-masked]
Date: Fri, 17 May 2002 13:06:30 -0600

1) there isn't end-to-end integrity ... there is a chain of trust .... that
has to be stiched together to approx. some end-to-end operatio; then we are
back to the original point about the security being only as strong as the
weakest link.

2) you can either be using password/pki security bifurcation as

a) transition solution not a security solution (as in the original post) or

b) the approving agency signs something that the external agencies trust
... (aka as in VPN) and the external agencies need to have absolutely zero
awareness about the internal machinations and internal trust relationships,
and/or

c) creating a total fabrication that individuals are really signing stuff
when they aren't.

The difference between "b" and "c" ... is that the relying parties are
really relying on the signing agency ... in "b" there is a one-to-one
relationship between the signature and the trust relationship ... and in
"c" the trust relationship is significantly obfuscated with lots of
different key pairs that contribute nothing to the intrinsic trust
infrastructure.

[email-masked] on 5/17/2002 12:14 pm wrote:

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..

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 17 May 2002 13:26:33 -0700

At 11:54 AM 5/17/2002 -0700, you wrote:

>Yeah,
>
>I shouldn't have used that term.  Still, a CA has power to produce forgery,
>at least by issuing a fake certificate and then signing with that.

Trevor,

You are right about that.  Two unrelated parties cannot establish "instant 
end-to-end" trust, and a CA serves in the role of a "trusted introducer" of 
sorts.

The term "end-to-end" is usually applied to the "ongoing" nature of 
subsequent transactions, where trust in the initial certification is assumed.

An "initial forgery" is a single and isolated point of "foul play".  In 
contrast, a "trusted intermediary" has the opportunity for foul-play in any 
future transaction.

Cheers!

____tony____

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 17 May 2002 12:46:57 -0700

I'm suggesting this proxy could be used for anything a private key is used
for: signing, authenticating, decrypting.  The idea is just to let people
with only authentication mechanisms do PKI "stuff" in a simple fashion, by
having a server do it for them.  I agree this wouldn't satisfy current NR
requirements.  Nor would it be easy to add support for this into PKIX, so
this is more a concept I think is interesting, then an immediately practical
suggestion, and probably off-topic.  I discuss this in more detail here
though, if anyone's interested:
http://www.sigaba.com/products/whitepapers/delegatedCrypto.pdf

(Presented here, but they only have the preproceedings version online):
http://www.cs.dartmouth.edu/~pki02/

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Friday, May 17, 2002 12:00 PM
To: Trevor Perrin
Cc: [email-masked]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?

At 11:45 AM -0700 5/17/02, Trevor Perrin wrote:
>Hi Stephen,
>
>To seek clarification: I was suggesting the use of an "online", but not
>necessarily "inline", intermediary.  Ie, the communication might not flow
>through the intermediary, the client would just perform a request/response
>protocol with him to produce a signed statement, say.  Is "link" or
>"hop-to-hop" the appropriate term for that? 
>
>Regardless, my use of "end-to-end" was confusing and I'll avoid it in
>future.  Thanks,
>
>Trevor

Trevor,

Given the clarification above, this sort of scheme sounds more like a 
proxy authentication service, analogous to the many single signon 
techniques that have been developed, but applied here to signatures 
for NR purposes. Given the requirements imposed on signatures for NR 
purposes in many contexts, e.g., in the EU directive, it's not clear 
that any form of proxy would meet those requirements.

Steve

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 20 May 2002 16:33:36 +1200 (NZST)

Trevor Perrin <[email-masked]> writes:

>for: signing, authenticating, decrypting.  The idea is just to let people with
>only authentication mechanisms do PKI "stuff" in a simple fashion, by having a
>server do it for them.

Something similar is being done in the SEE PKI project 
(http://www.e-government.govt.nz/see/pki/index.asp, although some of the newer
documents covering this haven't been posted yet) as a means of letting people
use a PKI without having to go through the pain of actually having to use a
PKI.  This uses (among other approaches) proxies to front-end to a PKI to allow
existing/alternative mechanisms to be used.

Peter.

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 21 May 2002 10:44:54 -0700

Hi Peter,

I'm interested.  I hope you put up more information soon.  If you're talking
about the "Authentication Proxies" described in 6.9.2 of the "Authentication
Mechanisms" paper, then it's sort of a mirror-image to what I'm advocating,
ie
 - converting PKI authentications -> legacy (password) authentications to
make things easier on apps
versus
 - converting legacy authentications -> PKI operations to make things easier
on users/desktop software

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, May 19, 2002 9:34 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?

>for: signing, authenticating, decrypting.  The idea is just to let people
with

Something similar is being done in the SEE PKI project 
(http://www.e-government.govt.nz/see/pki/index.asp, although some of the
newer
documents covering this haven't been posted yet) as a means of letting
people
use a PKI without having to go through the pain of actually having to use a
PKI.  This uses (among other approaches) proxies to front-end to a PKI to
allow
existing/alternative mechanisms to be used.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 May 2002 14:46:01 +1200 (NZST)

Trevor Perrin <[email-masked]> writes:

>I'm interested.  I hope you put up more information soon. 

I'm kinda hoping they publish some implementation-experience stuff at some
point.  At the moment they've covered some of their experiences in various
talks, but I don't know if there's anything online.  Their approach has been
"We'll do whatever COTS software supports", rather than the more traditional
"We'll design a grand infrastructure and then spend years trying to get vendors
to create the tools to support it".  The resulting system is quite some way
removed from any traditional PKI, but then they've also managed to get the
whole thing up and running with minimal cost and time expenditure.  From the
PKI-traditionalist POV what they're doing is heresy, from the get-something-
working-without-excessive-effort POV it's great.

(Cool quote from one of the talks: "It's nice to be in ~12 hours out of phase
with the rest of the world because you can submit bug reports in the afternoon,
have the vendors fix their products overnight, and have the patches by 8am the
next day".  Even with their minimalist, don't-push-the-envelope approach,
interoperability between products from different vendors has been a significant
problem).

Peter.