[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary Trust x Delegation

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "David" == David P Kemp <dpkemp@missi.ncsc.mil> writes:
    David> In my mind, the issuer does not trust the recipient
    David> (verifier), nor does it request (politely or otherwise)
    David> that verifiers do anything.  Rather the verifier trusts the
    David> issuer.  The issuer does not create authorizations that can

  This is the SPKI model, except that due to self-signed certificates
(which is equivalent to local policy), the verifier and the ultimate are
always the same entity. X.509 folk do the same thing. The built in
root CA key is "local policy"

  The reality that SPKI attempts to deal with is that if you do not
allow entities to delegate authority to their agents, etc. then these
entities will simply loan out their private keys. Given these two
choices, SPKI says that it is better to have multiple private keys
with a way to delegate authority between them.
  
  Now, the place where we have all gotten mired in the muck is that if
A delegates authority X to B, and B delegates authority X to C, then
we see that this reduces to A delegating authority X to C.
  Where the trust comes in is that when A delegates to B, it is also
trusting B to:
	a) take appropriate care of its private keys
	b) not delegate to inappropriate entities
	c) not lend its keys to other entities

  The presence of a "may-delegate" flag (can someone remind me what
the decided mechanism was? Did we decide something?) indicates to B
that A trusts B to enforce (B).
  HOWEVER, B can always do delegation by just loaning its private
keys.  
  This is what is meant by being unable to "effectively" prevent
delegation. There is nothing that A can do that is 100% effective.

    David> regulations created by policymakers.  If you are stopped by
    David> the police, you can present a drivers license as evidence
    David> that you are eligible to drive; the police and the courts
    David> trust that the DMV has done it's job in accordance with
    David> policy.

  A driver's license with a photo is probably harder to loan than a
private key. The connection between the photo and the name, is
however, something that a traditional identity certificate can do. And
no, the CA does *not* delegate that authority to anyone, may-delegate
or not. (non-root CA's usually have some restriction put on them, so
they don't get the whole authority, and if they do, then there *is* a
trust relationship involved)

    David> In the X.509 model, the verifier is central.  The verifier

  I don't think that the models are that far apart.
  The difference is that pkix has dealt primary with identity certificates
at this point, and not with authorization certificates.

   :!mcr!:            |  Network security programming, currently
   Michael Richardson |     with DataFellows F-Secure IPSec
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBM431t6ZpLyXYhL+BAQFAKgMAjQTJ2BAbE1Qu4Mh/DAqyCXknhkWMHPeg
kzZI+2C5Og5SaopgGmUHIbTSQz4LB8giQVALkrExM7DXTXpsUjKP3tn6V91zZXgW
AQRAD/NcxhAsLRN4pliAEpo466rxeltu
=qnuB
-----END PGP SIGNATURE-----
References: