Subject: RE: X.509 ACs vs. SPKI?

From: "David P. Kemp" <[email-masked]>
Date: Tue, 25 May 1999 10:58:47 -0400 (EDT)

> From: "Ellison, Carl M" <[email-masked]>
> 
> Perhaps I used the wrong word.  The fact remains that the code that
> interprets a full X.509 certificate (including all extensions) needs
> to be aware of (to embody) the definitions found in some paper
> document.  This is by contrast with SPKI certificates that can be
> processed through tuple-reduction without any special knowledge about
> such paper documents.  That is why SPKI can have a single Trust Policy
> engine while X.509 requires a different one for each application (in
> the limit, for each root key).

There are only two places that the policy written in a paper document
can be understood/interpreted/enforced - in applications and in the
user's brain.  To the extent that application engines perform automated
reduction, the user's workload (and ability to make mistakes) is
reduced.

Claiming that SPKI "can have" a single engine while X.509 "requires" a
different one for each root is one way of spinning it. But I would say
SPKI permits only a single engine, whereas X.509, which defines no
authorization mechanism itself, provides extensions identified by OIDs
which can select the engine to be used.  Automated authorization is not
a mature field; there are numerous candidates:  NIST's Role Based
Access Control, SPKI tuples, Novell's Security Attributes, the DoD's
SDN.801, and many others.  In 10 years, perhaps everyone will agree
that SPKI tuple-reduction is a suitable mechanism for automated
authorization decisions, and everyone's X.509 root cert will have an
extension that specifies an SPKI tuple reduction engine in conjunction
with some application-domain-specific parameters.

As for human-interpreted policy processing, one size will never fit
all.  VeriSign has 4 public assurance classes, the U.S. DoD defines 5
classes although only 2 are presently used, and other governments and
organizations have multiple CPs.  Harmonization (and elimination of
policy mapping) would be great, but it won't happen quickly, if ever.
Policy Qualifiers can be used to advertise quantitative information
such as Reliance Limits from the issuer to the RP, but if the intent is
automated processing rather than simply displaying information to the
user, I believe a different extension, specifying a "standard engine"
should be used.  The fewer engines applications have to support, the
better, but I don't think the market is yet convinced that SPKI tuples
are capable of supplanting RBAC, DoD PRBAC/LRBAC, other chaining
mechanisms, and plain old ACLs for all public-key-based authorization
applications.

That is why X.509 allows a choice of engines, including "display this
to the user", messy though the choice may be.

---

From: Carl Ellison <[email-masked]>
Date: Tue, 25 May 1999 19:02:35 -0700

"David P. Kemp" wrote:
[snip]
> SDN.801, and many others.  In 10 years, perhaps everyone will agree

[...]

> mechanisms, and plain old ACLs for all public-key-based authorization

Hi David.

You're right.  We haven't demonstrated all that yet.  We haven't
tried, yet.  However, I'm confident we will be able to and I look
forward to the resulting interaction either way the demo turns out.

 - Carl

-- 
 Carl M. Ellison   [email-masked]     http://www.pobox.com/~cme
 PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2
 ``Officer, officer, arrest that man!  He's whistling a dirty song.''
     [Jean Ellison]

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 26 May 1999 10:11:38 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of David P. Kemp
> Sent: Tuesday, May 25, 1999 9:59 AM
> To: [email-masked]; [email-masked]
> Subject: RE: X.509 ACs vs. SPKI?
> 
> 

This is a not how commercial trust works - I do respect that
your model fits classical military centralized
key management thinking, however.

In the commercial world, auditors have primacy over
contractor folks like VeriSign. That KPMG gives a representation
to VeriSign clients' auditors, concerning VeriSign
policy and veriSign's adherence to its own rules, is
what matters.

Whether KPMG is qualified to make such representation
is of course for the client to judge. In general,
the simple financial responsibility of KPMG - when making
meta-statements about the policies of others - is what will
drive the client.

I see a world emerging fast where the likes of KPMG issue
the (indirect) CRLs/OCSP responses/X509 ACs, given VeriSign 
manufacturers and issues id-certs.  KPMG qualifies the certs 
status as above, and thereby continues to assert its 
representations about VeriSign policy compliance.

So, rather than issuing and revoking a cross-certificate, or 
a Root Registry certificate, etc,. KPMG's policy adherence group 
qualify the cert status msgs. The relying  party is better 
protected; and it works today!. KPMG can use the outsourcing 
services of branded PKI players like DST - Digital Signature Trust,  
perhaps...

Caveat: Use of KPMG and VeriSign as players in the denovo 
PKI world are example well-known names, merely. One could 
substitute using NSA and DoD, VISA and its members, or Bank 
of England and BCCI, similarly. Almost all service industries 
have these relationships already in place... with natural 
policy-regulators and suborned providers.