RE: Self-signed root transport and CA expiration

["Hoffman, Mort" <Hoffman@xxxxxxxxxxxxxxxxxx>]

Peter,

Sorry for responding so slowly, but you left me (and pkix) off your
to/cc list, and while I got your first message on pkix, I did not get
your latter message at all.

I am quite familiar with Web of Trust models, and there are certainly
applications where it is a serviceable and even desireable model.
However, there are other applications, many of them non-military, where
such a model is weak.  In particular, I consider the retail banking
model one such model.  If everyone individually decides who to trust
based on private criteria, then I'm not sure how disputes get resolved.
My suspicion is that it would be far more expensive, when MasterCard
needs to check out Joe's personal certificate generation program to
decide if it is willing to trust or challenge Mary's assertion that it
must be a good signature because Joe said so.

Indeed, the viability of the whole CA business may be based on this
problem!  Clearly, this is not to challenge the notion of multiple trust
points that X.509 so clearly includes in its model.  From my own
perspective, when there are a relatively small number of them, I would
characterize it as cross-certification rather than root-less.  If
Verisign asserts that it has no root, it seems to be suggesting that
its' certificates should only be trusted based on personal faith -- we
all have faith (of some sorts), but they tend not to be consistent
enough to each other to form the basis of commercial trust.

I guess the other part of the discussion pertained to the lack of root
certificate of the (pardon my personal description of the beast) Versign
root.  Do I understand you correctly that the reason is that X.509 would
make you have a certificate expiration date if you had a certificate, so
that you avoid the problem by avoiding the certificate?  Surely you
could issue a new certificate if you still liked the key ...  It only
need happen every few years.

Mort
----------------------------------------

Mort,

If you read the self-governing regulations for the VeriSign public
certification
services (CPS), you will notice the declaration of a "VeriSign Root" -
an 
authority
with a defined function, which serves to register public key of
*VeriSign* CAs, 
and which
outputs a package known as a self-signed public key (read the document
for
precise terminology). Said package exists for the purpose of conveying
a trust point (see X.509) for use in the context of administering
local security policy of systems which wish to validate user certs which
impelment some control system (MOA, key distribution, etc)

The transport vehicle used to convey trust points and assure their
authenticity 
when used in a validating system can be a Fortezza
card slot, else a EMV smartcard public key slot or EMV smarctard reader
trusted 
terminal.
Other proprietary techniques exist on a per token basis which may
not be be based on public key techniques. It may also be a Netscape
technique for learning trust points dynamically. Ask the vendor
of the local security policy enforcing MIB!

You and I differ on protocol-bound chain semantics for internet
protocols; I try
to best follow the X.509 std in that within a useful trust chain is a
trust 
point. It may
be at the top, it may be in the middle, it may be at the level of a user
certificate. it may
not even be present within the set of certs of which the party which
quotes a user cert is even aware of. Such knowledge may be hidden
for sensitivity reasons. In OSI and PEM protocols, the cert bag sent
to accompany a protected service may even allow for suggest selection of
multiple
common trust points by the receipient. (* SSL does not seem to have this
flexibility)

The mechanism which enables trust points to
be entered into the local security context is not internationally 
standardized to my knowledge, though X.509 tailored profiles for
speciifc 
environments,
such as SET and 1422, do specify their own mechanism for gaining the
knowledge 
of at
least one trust point (SET Root and IPRA). Just as there will be many
escrow 
solutions, there
should be many mechanisms for learning/hiding trust points which
instrument a 
local policy
of reliance on the control system facilitated by certs. And this is the
heart ot 
Tim's
question, I believe.

In other non 1422-like models, there is only one trust point of
consequence - 
the public 
key of the most local CA to a relying party, else a relying parties own
signing 
key
in the degenerate case.

By determining  a common point of trust, and merging a locally generated
partial
path, with a path truncated at the common trust point, a recipient
releases
no knowlege of the use of, or makes any assumption upon, any particular
public "root" - rather the public key used to begin a trust path
evaulation
is always highly localised, and cert chains are "constructed" to ensure
a 
complete
set of intermediate certs which validate the user cert to be relied on,
and for which local audit records are kept.

This process is fully disclosed in X.509 std. The aim is to learn (but
not 
necesarily
displose) common points of trust. (These may be subject to non-std
systems of 
local
policy acceptance when determining their acceptability for a given
purpose, and their utility in path formulation for a given 
sensitivity/criticality of
a given user cert validation and its use to enable the
protection service).

Unelss you consider the user CAs public key, else the users own signing
key, to be a "root", the notion of trust point is far more useful (and
X.509 
standard). The
VeriSign PCS plans for a classical 1422 root, as a means (in an
acntipcated
dynamic and changing, multi-common-trust-point finding environment)
of finding at least one path through the maze. Following establishment
of
some basic channel, parties can, over that channel, perform key
distirbution
for subsequent association, according to different rules which may not
be made
public.

For a competent discussion of this, see X.509. Im just someone who
implements
stds as best & as fully as I can; Im not someone who writes them! All
errors of understanding are mine own.

The nice thing about X.509 (in general case) is that I dont have to
disclose, as 
a recipient,
which trust chain I used in validating. Though a party may be able
to learn that I used a security service which relies upon his/her cert,
they may not be able to learn what trust path I relied upon (or had
knowledge
of the existance of) in my decision taking. This affects the balance of
power in court.

So,

When is a root not a root?. When its just a key, like any other.

When can I rely on a cert? when you have determined/used your trust
point
and any necessary common trust points necessary for path detemination
and evaluation of security, and at least one statement of issuing policy
for any cert in a chain, prior to reliance.

Peter.

--------------
Morton D. Hoffman     GTE Cybertrust          hoffman@cybertrust.gte.com
(617) 455-2413           Fax (617) 455-3105