RE: clarification proposal -- Re: Current status of CRL validation ?

Stephen Kent <kent@bbn.com> Tue, 06 April 2004 21:09 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27359 for <pkix-archive@lists.ietf.org>; Tue, 6 Apr 2004 17:09:47 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36Jtt4i077188; Tue, 6 Apr 2004 12:55:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i36JttOq077187; Tue, 6 Apr 2004 12:55:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36JtsPL077166 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 12:55:54 -0700 (PDT) (envelope-from kent@bbn.com)
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i36Jtn7d026798; Tue, 6 Apr 2004 15:55:52 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06020413bc98a68c8b3f@[128.89.89.75]>
In-Reply-To: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com>
References: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com>
Date: Tue, 06 Apr 2004 15:08:32 -0400
To: Santosh Chokhani <chokhani@orionsec.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Cc: ietf-pkix@imc.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

At 1:56 PM -0400 4/6/04, Santosh Chokhani wrote:
>Steve:
>
>I do not have objection to parts of the first paragraph.  But, the first two
>sentences of the paragraph are not accurate by most interpretations.  I
>quote:
>
>"In X.509/PKIX only the issuer of a certificate can revoke it and there is
>only one issuer for a given certificate. Therefore, a certificate is either
>revoked or not."
>
>Through indirect CRL issuer mechanism (as defined in X.509 and in 3280), an
>indirect CRL issuer can revoke a certificate with or without the knowledge
>of the certificate issuing CA.  Since neither standard provide operations
>related guidance (lack of this guidance is appropriate in the case of both
>the standards), a subscriber can directly contact indirect CRL issuer and
>have their certificate placed on the CRL.

Good point. I overlooked that "feature" of the newer CRLs. Of course, 
I always thought it was a very questionable feature, so maybe I was 
pre-disposed to overlook it ;-)

The problem is not so much that a subscriber could ask someone other 
than the issuer of his cert to list it on an indirect CRL, but rather 
that we have no way for an RP to know whether certs listed in this 
way are appropriately revoked, in the general case. An indirect CRL 
is not authoritative for the entries that refer to certs issued by 
other CAs. In that sense I would still argue that only the issuer can 
revoke the certs that it issues. The use of indirect CRLs is much 
like using OCSP, in that an RP that is configured to accept 
revocation status data from a CA issuing an indirect CRL implicitly 
assumes that the CA is authorized to revoke whatever certs it chooses 
to list in this fashion. i don't think we would say that any OCSP 
server can revoke any cert, even though any server can issue a 
respnse that asserts that any cert is revoked. It's an issue of 
whether a RP is configured to accept status info from an OCSP server, 
or in the case of an indirect CRL, to accept indirect 
(non-authoritative) CRL entries.

Steve