Subject: Re: cA flag and CRL issuers (Addendum)

From: Tony Bartoletti <[email-masked]>
Date: Tue, 29 May 2001 17:29:07 -0700

Dave,

(Some clarification added at the end.)

I agree, "No one but the issuer can revoke that issuer's certification."

But the organization that is my employer should be able to revoke my 
ability to use or trust that certificate.  Moreover, they should be able to 
do so in a manner that is "global" to their body of employees, as easily as 
the CA itself might perform such a revocation.  It should NOT be required 
that each of 5000 employees "do something" via browser settings to effect 
the company's dictate for each such revocation (it could never happen in a 
timely or reliable manner.)

Why, exactly, the PKIX validation algorithm becomes off-limits to this 
endeavor, I am not sure.

I do not intend my comments to hold up PKIX acceptance.  My comments 
address the general concern over the assumptions and direction of future work.

Perhaps my concerns are misplaced, but a "very few" OS/browser vendors 
command the market, and having one's "root" certificate sitting warm and 
cozy in that environment is an enviable situation.  I imagine that 99% of 
casual users are blissfully unaware of how any of this works, and those 
vendors that benefit from the existing arrangement have little motivation 
to really put users in the driver's seat, on the chance they may drive off 
in another trust direction.  The user bought an OS, a browser, and have 
been quietly "opted-in" to a mysterious constellation of trust points, and 
indirectly trusted entities.

An organization (corporate, government) must be the final authority of 
trust for its employees (and, I would argue, individual citizens be their 
own final authority unless they choose to delegate these trust decisions.) 
Software should make it easy for an organization to install their own 
self-signed root certificate, use their "Org-CA-Key" to "certify" the other 
CA root certificates as they choose, and indicate any revocation mechanism 
they see fit.  This need "physically" impact the organization's N-thousand 
user systems only rarely, and thereafter the "standard PKI components" do 
their job as if nothing has changed.  Only the "root" has shifted.

Is there something inherently wrong with this vision? (Honest Question!)

CLARIFICATION:

I do understand why it "won't work" given the current profile 
dictates.  Current mechanics aside, is there something "philosophically" 
wrong with this vision?  The argument that "the user bought the OS, thus 
trust it, thus trust every (mostly hidden) thing it trusts in turn" 
disturbs me.  I suppose an organization could supplant the root of trust, 
but it seems they must climb over a mountain range of trees and rocks to do 
it.  (And given UCITA, it might even be illegal!)

___tony___

At 04:08 PM 5/29/01 -0400, David P. Kemp wrote:
>A Relying Party has the ability to control which CAs it trusts to issue
>certificates, and it also has the option of trusting public keys for which
>no CA has issued a certificate.  It likewise, as you say, has the option of
>accepting a certification which has expired or been revoked by its issuer,
>or refusing to accept, on a case-by-case basis, a certification which has
>not expired or been revoked.
>
>But despite the fact that the Relying Party is always in control of what
>that RP chooses to accept from others, RP applications need a specification
>(the PKIX profile) that tells how to reliably determine what the issuer of
>a certificate thinks about that certificate's current status.
>
>** No one but the issuer can revoke that issuer's certification. **
>
>You may wish to use the X.509 CertificateList data structure to contain
>some other authority's opinion of a certificate, or of the subject of
>that certificate.  That's fine, but you can't call it a CRL or process
>it using the PKIX path validation algorithm.
>
>Dave
>
>
>
>Tony Bartoletti wrote:
> >
> > Bob,
> >
> > I echo your sentiments.
> >
> > A certificate is fundamentally a statement by something called a CA, that
> > says, "We stand behind the associations embodied in this certificate until
> > we say otherwise (or it expires naturally.)"
> >
> > The fact that they made such an assertion, one way or another, is just one
> > piece of data in a relying party's particular trust model.  The RP may
> > either desire to "revoke trust" in that certificate, despite a CA's lack of
> > revocation, or may have reason to wish to continue relying upon a
> > certificate even though the issuing CA has revoked it.
> >
> > It is the Relying Party that Relies.  All others are simply factors in the
> > RP's trust calculation.
> >
> > And a rational PKI profile would recognize this fact and provide
> > corresponding guidance so that end-user products support user ease and
> > flexibility in local trust management.
> >
> > ___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900