Subject: Re: cA flag and CRL issuers

From: "David P. Kemp" <[email-masked]>
Date: Fri, 01 Jun 2001 09:29:03 -0400

Peter,

I agree with your seven assertions, with two caveats to number 6:

a) The OCSP and DPV documents should make an explicit declaration that
there are three, not two, modes of operation:
  1) Authorized,
  2) Trusted to provide CA status,
  3) Trusted to provide locally-determined status.

b) Third-party OCSP providers (those operated under the administrative
control of some entity other than the one responsible for approving RP
trust anchors) should be required to make available a CP, CPS, or
equivalent to all customer RPs, and that document must make an explicit
statement that the provided OCSP responses are "always consistent" or
"possibly inconsistent" with the status provided by the certificate
issuer.

I believe the PKIX model accommodates a local mode of online
status operation as long as there is full disclosure.  I believe the
PKIX model accommodates only Authorized signers of CRLs.

Dave

Peter Williams wrote:
> 
> I think this was very good news.
> 
> Let me put Steve's apparent statements in simpler, declarative form
> in which each numbered assertion is a self-contained truth devoid
> of context, other than perhaps assuming the truth of an earlier
> numbered assertion:
> 
> 1. OCSP can be used in side-effect modes.
> 
> 2. It is legitimate to use OCSP responder working in a
> side effect mode to achieve the goals T&B cite
> 
> 3. You can "rely" on an OCSP responder/response.
> 
> 4. You can combine an OCSP side effect mode with reliance
> on an OCSP responder/respose.
> 
> 5. A relying party can rely upon an OCSP responder working
> in side effect mode "V" as "a local means of asserting per-certificate
> validity
> judgements that might override those of the CA who issued a cert."
> 
> 6. To use and rely on an OCSP responder operating in side effect
> mode "V" is to be operating in a manner compatible with the PKIX
> overall model.
> 
> 7. The same general theory holds for a DPV server.
> 
> Do you agree that some or all of my numbered assertions are consistent
> with Steve's message, as you intepreted it?

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 1 Jun 2001 11:25:08 -0400

Dave Kemp wrote:

----- Original Message -----
From: "David P. Kemp" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 01, 2001 9:29 AM
Subject: Re: cA flag and CRL issuers

> PKIX model accommodates only Authorized signers of CRLs.

Why?

Why does PKIX allow/support/endorse different standards for different ways
of providing revocation information?

Is this an artifact of  "existing standards" vs. "new technology"?  i.e.
X.509 says only  CAs sign CRLs, so darn it, that's the way it is, but since
OCSP isn't in X.509 we can make any rules we want?

Is this because CRLs are "more secure" than OCSP responses?

Is this another step in our attempt to thoroughly discredit CRLs in favor of
the more modern OCSP?

I'm sorry, but this inconsistency just makes no sense to me.

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 01 Jun 2001 13:49:17 -0400

> > PKIX model accommodates only Authorized signers of CRLs.

Because I haven't seen a proposal for how policy-dependent CRLs would
work.

Consider CAs A, B, and C.  Consider local revocation authorities
X, Y, and Z.  Consider that a relying party could trust one or more
CAs and zero or more independent revocation authorities, and that it
could receive a different answer from each.  An online responder
knows who is asking the question, so it can both tailor the response 
and deliver it directly to the questioner.  A CRL generator has
to create the answer without knowing who is asking the question,
and the only way that works is if the answer is the same for every RP.

Also, Bob is complaining about the burden of going out and touching
every RP application.  I don't see how:
 1) modifying products to support separate trust anchors for
    certificates and CRLs, and then
 2) managing two sets of trust anchors instead of one
for every seat eases that burden.

> Is this another step in our attempt to thoroughly discredit CRLs in favor of

If you believe OCSP/DPV is the be-all and end-all in revocation, you
should be happy to see CRLs discredited.

I believe that CRLs and OCSP/DPV are complementary parts of a two-tier
revocation architecture.  I'll send under separate cover a paper explaining
why, but in short CRLs are used to communicate authoritative revocation
information from CAs out to relying organizations, and those organizations
have the option of using OCSP to communicate (perhaps with modification) that
information to individual applications.  Some applications, like scholars
who eschew translations in favor of reading the original Greek or Latin,
will want direct access to the authoritative CRLs signed by the original
issuer.

If you can come up with a detailed concrete proposal for how to generate,
store in a repository, deliver, and process in unmodified applications CRLs
that depend on local policy, and the proposal is both easier to understand
and easier to implement than issuer-signed CRLs, then perhaps I'll change my
mind.  Until then, I'll stick with the dictionary definition of revoke
(http://m-w.com/): "to annul by recalling or taking back".  You can't
take something back unless you issued it in the first place.

The simple statement that CRLs must be authorized by the certificate issuer
(i.e. that one CRL must be common across all RP environments) is just the
tip of the iceburg - if you relax it you're going to get hit with the
other 90% that is hidden underwater.

Dave