Subject: RE: Proxy PKI.

From: Trevor Perrin <[email-masked]>
Date: Wed, 22 May 2002 12:59:19 -0700

I like the proxy certificates approach, but it doesn't address my chief
complaint about PKI: semantics can only be expressed in certificates.  

Consider three organizations, each with a TTP of some sort:
 - A has an offline TTP, ie CA
   - CA issues certs to users, who sign, decrypt
 - B has an online TTP
   - users authenticate to TTP who signs, decrypts
 - C has an inline TTP
   - communications pass through TTP who signs, decrypts

Currently, B and C have to simulate A: ie, create a key pair and certificate
for each user, publish the certificates, etc..  These superfluous
certificates are needed because PKI only allows delegation of privilege in
the context of certificates, not operations.  Ie, a TTP can says "I trust
this public key to sign for Bob", but it can't say "I'm signing for Bob".
Similarly, it can say "I trust this public key to be encrypted to for Bob",
but no-one can encrypt to it and say "give this to Bob".

If semantics could be attached to operations, then B and C could function
much more naturally by simply signing and decrypting with a single key pair,
and would not have to pretend to be A.

-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 7:14 AM
To: Trevor Perrin
Cc: [email-masked]
Subject: Re: Proxy PKI.

Trevor Perrin wrote:
> 
> 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.

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. 

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

-- 

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