RE: Self-signed root transport and CA expiration

[Peter Williams <peter@xxxxxxxxxxxx>]

Mort,

Ill reply widely, given your legit moan, even though its off topic for an IETF work
list. I try to keep talk and work lists separate, in general ; I sometimes
forget though I try hard to be a good citizen on lists.

"Web of Trust" is almost a trademarked term - owned by PGPers. So
I dont use it (*), particularly as its PGP(tm) connotation is not what I
am asserting. (* except as intended by PGPers)

I am asserting X.509 (not-tm),  which has a defined procedure and internationally
standardised syntaxes for determining both forward and reverse cert
paths which, when combined, enable joint agreement of common points
of trust, not necessarily known a priori. it also has a procedure
and clauses which say - you can do whatever you like, if
you dont think this fits your needs.

This procedure has little to do with PGP, as we know it. It has lots to
do with corporate and public management domains, and scaling up an multi-domain
mixed private and public authentication infrastructures to allow both interworking,
use of any mass-market application, AND instrument localization
of authentication security policy when relying on the infrastructure.

I would have expected you to support, in general, standard procedures
ratified internationally. Whether any given path determination
system is suitable for a given environment of application is always a matter
for local system designers. 

Im sorry, Mort; I just dont subscribe to the "one true way". I was
trained to be a utilitarian. if PGP format certs is what customers want,
you can be sure VeriSign will be providing them. Ill argue for
standards use as ever, but I will not force them on people who dont want
them. Similarly,. Ill advise the benefits of hierarchical elements 
in key management domain mgt to promote the bigger PKI; but Im not going to
force the pace nor the nature of open networking theory on those who,say, definitively
want the commercial privacy properties of the  Entrust n*n peer-peer model. I do
see the procedure of X.509 for common trust point determination
as being that which, over time, will allow mix and match of
whatever gets shipped during the first five years of our industry. I
dont expect the Internet PKI to get built overnight.

Contrary to the first 20 years of commercial key management services
sold to militaries, there is unlikely to be any one way of doing *it*
in the commercial world. Companies which are succesful in this
space think open, and be open. Im glad to see a major company like GTE
(and  with GTE's fine symmetric-key management credentials)
finally taking part openly in the pertinent IETF forum! I just
wish Motorola GEG would step up their activity, too,
to ensure we get the benfit of their systems-wide experience
and MISSI/NSA work.

Do you have any comments on what youd like changed in the PKIX drafts
which you are willing to share on the mailing list?

Do you share VeriSign's hope that the industry moves to implement
and offer services/products which seek to conform to the specs
ASAP, when engaged in IETF layer protocols like PEM, TLS, IPSEC,
etc.


 ----------
From: 	Hoffman, Mort
Sent: 	Wednesday, November 20, 1996 11:43 AM
To: 	'peter@verisign.com'; 'ssl-talk@netscape.com'; 'ietf-pkix@tandem.com'
Subject: 	RE: Self-signed root transport and CA expiration

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