[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: manual keying and IPSEC conformance
Mike Smith wrote:
>
> "Trust chains Always begin at the verifier". In a situation where a
> corporation has established (or outsourced) a CA function, the
> "verifiers" would be in the trust hierarchy of the corporation, not at
> the individual. I believe that the corporate CA would be the entity
> specifying or allowing THEIR trust to be extended to extrnal entities
> (such as authorized vendors' CAs, etc.)
>
> Michael
>
> >>> David P. Kemp <dpkemp@missi.ncsc.mil> 08/21/97 08:31AM >>>
> > From: Ran Atkinson <rja@inet.org>
> >
> > In the X.509 arena there are MANY folks in the CA business competing
> with
> > each other, but cross-certification is not yet an element of the
> real world.
> > What if I want to talk with user FOO, but I use CA==X, FOO uses
> CA==Y
> > where (Y!=X) and (X,Y don't cross certify each other) -- result, no
> secure packets.
>
> This is a common misperception about X.509. The ISO/ITU X.509
> standard
> has always explicitly supported arbitrary trust chaining paths (a.k.a.
> "web-of-trust") but, perhaps due to the PEM experience, most IETF'ers
> seem to regard X.509 as requiring strict single-rooted or
> cross-certified multiply-rooted hierarchies.
>
> Kudos to the SPKI folks for making explicit the notion that trust
> chains
> always begin at the verifier. The PKIX folks perhaps should add some
> verbiage that makes it clearer that the verifier can choose to trust
> whomever it wants. That verbiage shouldn't be necessary, but there is
> apparently a huge PEM legacy-of-perception that needs to be erased.
>
> In the IPsec case, if Ran "uses" (has a certificate issued by) CA==X,
> and FOO has a certificate from CA==Y, there is not necessarily a
> problem.
> As long as Ran's machine has a Ran-issued cert for CA==Y
> stating that Ran trusts Y to certify IPsec nodes (perhaps with
> name space or policy constraints), then there is no need for X and Y
> to be cross certified.
>
> More generally, each administrative domain would have a single
> root public key, each node within the domain would trust *only* that
> root key, and the domain root would certify *all* CAs which are to be
> trusted by nodes within the domain. The same mechanism is used to
> address the privilege side of the compartmented information problem
> that was recently brought up. (The other side of the problem is
> data labelling.)
>
>
The American Bar Association is discussing nine models of PKI, including
"open pki" where all trust chains lead to a CA doing business with the
public, like Verisign or Thawte, "closed pki" where my CA issues certs
that are usable only in my systems (eg Bank X certs usable only to
access Bank X accounts via Bank X websites) and "membership pki" which I
think is close to what Mike is discussing.