Subject: RE: Proxy PKI.

From: Trevor Perrin <[email-masked]>
Date: Tue, 21 May 2002 23:28:15 -0700

Hello PKIX,

Here's one way of looking at "proxy PKI".  I won't keep spamming the list
about this, but I just wanted to throw it out there once..  I'd love any
feedback, or hearing about similar thoughts/projects.

With PKI, it's implicitly assumed that when something verifies with a public
key, this key is "speaking for" everyone in its certificate, and when
something is encrypted to this key, it is "heard by" everyone in the
certificate.  Thus, if a group certificate is used, it is left unspecified
which member of the group is actually sending/should receive the data.

Ie, PKI allows the semantics
 - K1 says K2 speaks and hears for x (certificate)
 - K2 says y (signature)
 - only K2 hears y (encryption)

But does not allow indirect statements, like
 - K1 says "x says y"
 - only K1 hears "only x should hear y"

(K1, K2 are public keys, x is some set of named principals, y is some
document)

This indirection would allow PKI "gateways", which would represent entities
in security domains that are not otherwise part of the PKI.  In particular,
clients who don't want the burdens of managing their own key pair or
interfacing with PKI could authenticate to such gateways using simple
methods like passwords.  These gateways could be inline with the
communication path, like S/MIME Domain Security, or perpendicular to it,
where clients call out to the gateways to perform signatures and
decryptions.

With this indirection, statements can be made two different ways: either
directly or indirectly.  This suggests we separate *how* things are said
from *what* is being said.  Ignoring encryption, what can be said is:
 - "K speaks for x" (introduction)
 - "x says y" (attribution)
 - application data
The first corresponds to the to-be-signed content of a certificate, where x
specifies the name(s) associated with public key K.  The second is similar,
but instead of associating x with a public key, x is associated with a
particular statement y, represented by its hash value.

Statements can be made by:
 - signing them directly with a private key
 - attributing them (i.e. including their hash value as y above)

Introductions and attributions could be chained arbitrarily, but since
they're both defined on the same names, they can be processed uniformly by
certificate validation logic.  A chain would be like:
 - K1 says K2 speaks for a* (signed introduction, ie certificate)
 - K2 says K3 speaks for a* (signed introduction)
 - K3 says a* says          (signed attribution)
  - ab* says                (attributed attribution)
   - abc* says              (attributed attribution)
    - K4 speaks for abcd*   (attributed introduction)
 - K4 says abcde* says      (signed attribution)
  - K5 speaks for abcdef*   (attributed introduction)
 - K5 says acdef* says      (signed attribution)
  - abcdefg* says           (attributed attribution)
   - acdefgh says           (attributed attribution)
    - hi                    (attributed application data)

The attribution chains could be collapsed.  Intuitively, instead of saying
"Alice says Bob says Charlie says hi", I could just say "Charlie says hi",
assuming I trust Alice and Bob.  But if I explicitly mention them, then
later on when I (or you) discover that Alice is untrustworthy, it becomes
easier to recover.

This may not justify the complexity of nested attributions.  We could make
things simpler by disallowing attributions except in the final signature
over application data.  This would give a more conventional certificate
chain, but where the end-entity can explicitly represent who he is signing
on behalf of:
 - K1 says K2 speaks for a*
 - K2 says K3 speaks for a*
 - K3 says K4 speaks for acbd*
 - K4 says K5 speaks for acdef*
 - K5 says abcdefgh says
  - hi 

This last attribution could be represented in a variety of ways, for example
embedding a SAML Assertion as a signed property of an XML Signature.  The
inverse notion, an encryption instructing a particular public key whom to
give the encrypted data to, could be represented by a similar idiom
involving XML Encryption and XACML.  A request/response protocol could be
defined allowing clients to delegate processing of these structures to their
"PKI gateways".  

The paper I mentioned a couple mails ago discusses this and also trying to
represent this in X.509.  If a standard way to bind names into these signed
hashes and encrypted symmetric keys could be decided on, then potentially,
application protocols could be modified to use these and thus support PKI
gateways, allowing people with only passwords to do S/MIME mail, TLS client
authentication, etc..

Trevor

-----Original Message-----
From: Trevor Perrin [mailto:[email-masked]]
Sent: Tuesday, May 21, 2002 10:45 AM
To: [email-masked]'; Trevor Perrin; [email-masked]
Cc: [email-masked]
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?

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?

Trevor Perrin <[email-masked]> writes:

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

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: "Douglas E. Engert" <[email-masked]>
Date: Wed, 22 May 2002 09:14:16 -0500

> feedback, or hearing about similar thoughts/projects.

You should look a the Globus Project at http://www.globus.org
The GSI is a GSSAPI built on top of SSL. It uses proxy certificates
to delegate. 

The proxies used with the GSI today are the inspiration for: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-02.txt

So although the proxy you are describing is not the same, some of the
concepts are similar, as the GSI proxies are delegated to others to act
on behalf of a user. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444