Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]

From: Peter Williams <[email-masked]>
Date: Thu, 29 Jun 2000 09:54:54 -0700

Rich/Aram,

The OCSP model got it - the control constructs - about right, I 
suggest. There, a key management model was embedded in the RFC that 
leveraged both hierarchical control systems theory (2459) and 
non-control-oriented constructs for authenticating the public 
keys of the responder to the service user.
 
OCSP used a specific set of concepts for orchestrating
the control relationships between the parties. These went
beyond the notion of "delegation of authority via
certificates" - a parochial construct from the proprietary system 
security designs of the late 70s and 80s - a reflection of a certain 
era of designed-in integrity for distributed systems.

TSA should do the same as OCSP, I suggest.  The simplistic military
security model in which TSAs are "granted authority to act" by
a CA is doubtfully sufficient for the Internet environment
that we profile here. The commercial, political and
practical realities make such a simple model as impractical
as the same model was for OCSP.  

I doubt we would now have the various validation networks that
we see popping up if the OCSP standard had not had
the flexibility to adapt to various ideas of control, as
decided by the deployment community. OCSP
enabled us (a significant OCSP vendor/user community now) to 
deploy switched, proxied, cached, pushed, pulled and delegated 
forms of validation  authorities (OCSP responders) as the 
risk management culture demanded.

To engender a successful, commercially-driven, multi-vendor,
value-adding, open TSA industry, we  should perhaps follow the 
OCSP lead. We should again use interworking-standards consensus to 
help form another round  of open, Internet infrastructure. Ensuring 
that there are various models of control - that relying parties apply
under their own models of risk management - seems vital: only 
those Internet security standards with the required degree of openness
in the control area seem to get adopted in practice.

Peter.
 
-----Original Message-----
From: Rich Salz [mailto:[email-masked]]
Sent: Thursday, June 29, 2000 8:41 AM
To: Aram Perez
Cc: PKIX
Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> Why do you want to force me to figure out the OOB mechanism for every new
> PKIX service?

I don't.  I want it to be possible.  Surely you see the difference.

Without a self-signed cert, my service has to either
 1	Run a CA, doubling the amount of private key material I maintain; or
 2	Go to someone else's CA, who might be a competitor, and convince
	them to perform the due diligence necessary to certify me as a TSA;
or
 3	Repeat step 2 with "every" CA a potential customer might know.

I don't believe it's reasonable claim that just because it's a CA, it is
qualified to certify TSA usage.  "Trusted to sign end-entitities without
these eKU values" is not a feasible trust model.
	/r$

---

From: Aram Perez <[email-masked]>
Date: Thu, 29 Jun 2000 12:58:11 -0700

Hi Peter,

While I mostly agree with you, this is the PKIX (where the X is for X.509)
with is by definition hierarchical (or "parochial" as you put it). I'm not
sure where this notion of "delegation of authority via certificates" comes
from or the concept of "trust me, I have a certificate from XYZ (a CA)", but
I certain am not a believer or practitioner of it. In a PKIX world, I only
want a CA to bind some identity and a public key. I will establish authority
and trust via other mechanisms that are not necessarily tied to a CA and/or
certificates.

Regards,
Aram Perez