Subject: RE: cA flag and CRL issuers

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 29 May 2001 11:28:59 -0600

Michael,

I commented on this earlier, but no one picked up on it.  Maybe it got lost in the noise.

Generally, I would agree with you.  However, the entire purpose of PKI is to serve the needs of the relying party, first and foremost.  And since the most cases the relying party is a member of an organization that may wish to impose some collective rules for processing certificates, I believe that necessitates the ability to have the option for LOCAL control over CRLs and OCSP responses.

Since in the general the subscriber or issuing CA may not even know who the relying parties may be, this means in particular that it is NOT always possible, nor desirable to require that the source of a CRL must necessarily be named in advance, for example in a CRLDistributionPoint, or signed or otherwise anointed by the CA, for that would turn the relying party trust model on its head.

So I would rephrase your requirement to state that the provenance of a certificate, including its current validity and trust status or lack thereof, must link back in a technical fashion to a trust root installed in the relying party's software.  Assuming that the CA's, AA's, etc., root is installed the RP software, your requirement is a proper subset of what I am proposing.

"Is there anyone else thinking same way, or am I unique in this perspective?"

Bob

Robert R. Jueneman
Security Architect

Novell, Inc -- the leading provider of Net services software

>>> "Michael Myers" <[email-masked]> 05/29/01 11:07AM >>>
All,

Regarding this thread, it seems to me that whether setting the cA bit for PK
certs, establishing algorithmic logic regarding naming or authorizations,
maybe in the long run inventing a cA bit equivalent for ACs or whatever
other technical mechanism we may devise, there exists a meta-requirement
that the provenance of a digital credential MUST link back in a technical
fashion to the source of its original issuance.  Is anyone else thinking the
same way or am I unique in this perspective?

Mike

Michael Myers
t: +415.819.1362
e: mailto:[email-masked] 
w: http://www.traceroutesecurity.com

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 29 May 2001 12:14:03 -0700

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___

At 11:28 AM 5/29/01 -0600, Bob Jueneman wrote:
>Generally, I would agree with you.  However, the entire purpose of PKI is 
>to serve the needs of the relying party, first and foremost.  And since 
>the most cases the relying party is a member of an organization that may 
>wish to impose some collective rules for processing certificates, I 
>believe that necessitates the ability to have the option for LOCAL control 
>over CRLs and OCSP responses.
>
>Since in the general the subscriber or issuing CA may not even know who 
>the relying parties may be, this means in particular that it is NOT always 
>possible, nor desirable to require that the source of a CRL must 
>necessarily be named in advance, for example in a CRLDistributionPoint, or 
>signed or otherwise anointed by the CA, for that would turn the relying 
>party trust model on its head.
>
>So I would rephrase your requirement to state that the provenance of a 
>certificate, including its current validity and trust status or lack 
>thereof, must link back in a technical fashion to a trust root installed 
>in the relying party's software.  Assuming that the CA's, AA's, etc., root 
>is installed the RP software, your requirement is a proper subset of what 
>I am proposing.
>

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

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 29 May 2001 16:08:21 -0400

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

---

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

Dave,

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!)

___tony___

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 May 2001 22:23:45 -0400

Tony & Bob,

This discussion re revocation seems to be colored by excessive use of 
the term "trust."  It's common to use that term in discussing PKIs, 
and the public CA approach to PKI, exemplified by VeriSIgn, 
encourages that notion, because such CA are viable only if "trusted."

However, that is not the only way to think about roles in a PKI.  If 
CAs are aligned with physical world entities that are authoritative 
for the data contained in certs, e.g., companies issuing certs for 
employees, then these CAs are not "trusted" in the same way that one 
trusts a public CA.  Moreover, CAs of this sort are authoritative for 
revocation, just as they are authoritative for cert issuance. Tony 
seems to agree with this observation, but Bob feels that this is a 
naive model re NR.  I will remind Bob that NR is not the only focus 
of PKI, that this WG has expended way to much time arguing about NR 
matters that seem to never be fully resolved in the technical domain, 
and that the lack of uniform agreement re NR requirements suggests 
that no single view of technical support for NR can be considered 
authoritative.

What you tow are suggesting is a local means of asserting 
per-certificate validity judgements that might override those of the 
CA who issued a cert. While I can appreciate the motivations that you 
cite for this, they are simply not consistent with the overall X.509 
or PKIX models. We cannot tailor the specs to compensate for 
questionable PKI implementation designs in apps such as browsers.

OCSP does allow for local configuration of a local source for 
revocation information, and that would allow one to achieve the goals 
you cite, if one relied on OCSP for revocation status.  DPV will 
allow a similar configuration capability. So, I suggest that you be 
content with the ability to achieve the stated effects via these 
other protocols, which will provide the capability as a side effect 
of their other design goals.

Steve