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

Closed loop paths of trust



> To me, there are not apples and speedboats.  Rather, there is
authorization 
>which is injected by the verifier into a so-called root key and passed 
>from that root key through certificates, possibly constrained or
restricted, 
>into the eventual request where it is delivered to the verifier as part of
a 
>request for some kind of action.  This model of trust computation fits all
>known certification examples.  Even though it is foreign to X.509 thinking,
>in particular, it applies to X.509.  The authorization in this example
flows
>in a loop (circuit) from verifier back to verifier.  To use an electrical 
>example, the verifier has both battery and ammeter.
>
> - Carl

At least with respect to X.509 v3 and the PKIX work, it is definitely not
foreign.  There is a continuing and erroneous belief that X.509 is
inherently a top-down trust structure, but this is not the case.

Especially once smart cards with tamper-proof storage for root keys become
popular, I would expect that at least for large organizations the following
will occur:

1.  The MIS or IT organization will issue smart cards containing one or more
public root keys created by the MIS/IT organization.  The root keys will be
embedded in self-signed X.509 certificates containing the organization DN
(for convenience, primarily), together with validity periods, etc.  These
certificate are not necessarily published anywhere, except in the smart
cards issued to employees, so as to minimize any potential liability that
might be caused by using that key to certify other keys.

2.  The self-signed certificates will contain a PolicyConstraint OID
attribute, specifying what other CA's policies are to be considered
acceptable as far as official business is concerned.

3.  The MIS/IT organization may choose to unilaterally cross-certify other
CAs that it trusts, and may in addition provide for policy OID mapping.  For
example, for high value transactions, it might certify an internal CA used
to issue certificates to corporate officers. In addition, now that the State
of Utah has officially certified Digital Signature Trust Co as a licensed CA
under the Utah Digital Signature Act, they might certify certificates from
the State of Utah and from DSTC.  Florida is about to adopt regulations
setting up a rather similar structure, and although it is unknown whether
either Utah or Florida will certify each other, the IT organization might
decide that Florida's certificates are good enough for their purposes, and
certify their public keys as well.

4. Eventually, Utah, Florida, and other states will get around to issuing
certificate to both public CAs like VeriSign, and to private corporations
who operate CAs for their own employees. These various CAs will not
necessarily meet the same strict standards for identification, technical
controls, liability, etc, nor should they.  So the user's IT organization
(or the user himself)  can create perhaps three categories of chains of
trust, called for example Classic, Gold, and Platinum, for various usages. 
Using the policy mapping option, they can map to a hypothetical Utah Red,
White, and Blue series of certificates, to a Florida Pink, Aqua, and Stucco
series; and an Illinois Diamond, Ruby, and Pearl series.  Eventually, those
licensed/accredited CAs may set up equivalent policy mapping controls to map
their series to say an IBM blue, bluer, and true blue series.  (You can have
any color certificate you want from Ford, of course, as long as it is
black.)

5.  Depending on the user's own trust requirements (suitably influenced or
constrained by corporate policy :-), individual applications, and even
different uses of an individual application (S/MIME, for example) may select
a particular color coded trust hierarchy, starting with the appropriate root
certificate and enforced by the policy OID constraints.

6. Once that initial selection is made, assuming that the user's software
correctly implements the certificate validation rules and that the various
intermediate CAs are legally or contractually constrained and audited
appropriately to ensure that the trust is really operable, the user/verifier
can select the appropriate trust environment for the intended use, and have
everything else happen automatically.  In particular, and this is one of the
most important features, if the smart card is trusted and has the
intelligence to validate the certificate chain itself, a digital signature
can be validated without having to rely on untrusted software, OR ON LOCAL
DATABASES.

Since it is the user who chooses which root key to use for particular
applications (at least from the set that is provided to him by his IT
organization), the validation is neither top down, nor bottom up, but both,
in a loop, as Carl has discussed.

(Having said that, I am inclined to wonder whether, after all of this time
and discussion, the SPKI group has developed anything that is sufficiently
different from what the PKIX has developed to be worth the beans, or whether
this has merely been a rather arcane, theological exercise of no practical
benefit. Obviously Carl would disagree with that assessment, and I know him
well enough to know that he is quite sincere in his beliefs.  But I would be
curious to know just who else among the vendor community is prepared to put
their money where their mouth is, and to commit to develop and support
actual products based on this specification?)

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."