Subject: Re: What is the meaning of the "indirectCRL" flag

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 30 May 2000 16:04:38 -0600

Al, a belated comment on your note below.

I agree with the statement that normally, only the entity that issued
the certificate is allowed to revoke it, or more generally to respond negatively
to an inquiry about certificate status.

But there ares some exceptions, notably where the relying party, or the relying
party's Enterprise, is capable of making their own decisions about the trust implications
about the end-user's certificate.

It is not beyond the realm of possibility that a given Enterprise might want to have
their own say-so about whom they trust, regardless of what some CA thinks about the 
status of a given user.  That user may have exceeded their credit line, gone bankrupt, 
have been convicted of a felony, be under investigation in connection with various
financial irregularities, etc., none of which would necessary force a CA to revoke his 
certificate.

The relying party would no longer choose to TRUST that individual, regardless of what
the CA might think of him. 

Presumably the relying party's Enterprise should be allowed to issue in internal-only CRL 
or the equivalent, and have it be accepted by the various relying parties, so long as that 
Enterprise's certificate is in the relying party's cache of trusted CA certificates, whether
or not the name of that Enterprise had previously be listed in the Certificate Issuer Extension.

Regards,

Bob

>>> Al Arsenault <[email-masked]> 05/25/00 07:29AM >>>
Christopher:

	An "indirect CRL" is a CRL issued by an entity other than the one that
issued the certificate(s) on the CRL. The relevance of this flag is
mostly explained in section 5.3.4, namely

5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL
   indicator set in its issuing distribution point extension. If this
   extension is not present on the first entry in an indirect CRL, the
   certificate issuer defaults to the CRL issuer. On subsequent entries
   in an indirect CRL, if this extension is not present, the certificate
   issuer for the entry is the same as that for the preceding entry.

That is, the indirectCRL flag is used in combination with the
Certificate Issuer Extension to let you know that the issuer of the
certs in a CRL was different from the issuer of the CRL, and who it was.

(Normally, only the entity that issued the certificate is allowed to
revoke it; otherwise, you open yourself up to a nice denial of service
attack.  However, if you control it properly, this can be a nice
revocation management feature.)

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

Christopher Williams wrote:
> 
> RFC2459, section 5.2.5  "Issuing Distribution Point" mentions an indirectCRL
> flag, but does not give its significance.  Does anybody know?
> 
> Christopher Williams
> 
> Software engineer, NetLexis Ltd.
> Solutions for secure electronic commerce
> http://www.netlexis.com

---

From: Rich Salz <[email-masked]>
Date: Wed, 31 May 2000 09:41:18 -0400

> to an inquiry about certificate status.

I strongly disagree.

I believe that the more "important" or "valuable" a certificate is -- and I
am deliberately using vague terms since they are highly context-specific --
the longer and more involved the due-diligence/registration process should
be.  Therefore, your highly trusted, highly important CA should be off-line
except for those few moments when it needs to sign something.

Conversely (or should that be "perversely" :), in the event of a compromise
of one of those certificates, speed of revocation is paramount.  Therefore,
delegating revocation to an on-line, always-up, CRL (or OCSP) server is a
good thing.

It is MUCH easier to recover from believing faulty revocation than from
relying on a compromised certificate.
	/r$

---

From: Dan Geer <[email-masked]>
Date: Wed, 31 May 2000 11:30:16 -0400

> I believe that the more "important" or "valuable" a certificate is
  > -- and I am deliberately using vague terms since they are highly
  > context-specific -- the longer and more involved the
  > due-diligence/registration process should be.  Therefore, your
  > highly trusted, highly important CA should be off-line except for
  > those few moments when it needs to sign something.
  > 
  > Conversely (or should that be "perversely" :), in the event of a
  > compromise of one of those certificates, speed of revocation is
  > paramount.  Therefore, delegating revocation to an on-line,
  > always-up, CRL (or OCSP) server is a good thing.

downside risk due to certificate compromise:
* inversely proportional to certificate's depth in certification hierarchy

procedural costs of from-first-principles revocation testing:
* proportional to certificate's depth in certification hierarchy

because the above curves cross:
* separation of issuance and revocation is practically advantageous
* neglecting to check very distal certificates is economically rational

--dan