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

Stephen Kent <kent@bbn.com> Tue, 06 April 2004 15:13 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 LAA26843 for <pkix-archive@lists.ietf.org>; Tue, 6 Apr 2004 11:13:31 -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 i36DowTj052752; Tue, 6 Apr 2004 06:50:58 -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 i36Dowfa052751; Tue, 6 Apr 2004 06:50:58 -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 i36DovPH052735 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 06:50:57 -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 i36Doo7f002699; Tue, 6 Apr 2004 09:50:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p06020405bc9860671a8f@[128.89.89.75]>
In-Reply-To: <4071DE2E.B5BED74A@nma.com>
References: <20040323103412.GA23286@cryptolog.com> <004f01c410dc$2c0681d0$df294d0c@hq.orionsec.com> <20040323142525.GA27672@cryptolog.com> <p06020406bc861b0a4627@[128.33.244.157]> <406A0839.14F7C3A1@nma.com> <p06020401bc909a0b8ec1@[128.89.89.75]> <406B0593.FD2E1F6B@nma.com> <p06020408bc90bbc275a7@[128.89.89.75]> <406DE8AD.BC0DA38@nma.com> <p06020411bc9750745da7@[128.89.89.75]> <4071AB84.14898140@nma.com> <p0602041ebc977ad14b67@[128.89.89.75]> <4071DE2E.B5BED74A@nma.com>
Date: Tue, 06 Apr 2004 09:31:12 -0400
To: Ed Gerck <egerck@nma.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 3:31 PM -0700 4/5/04, Ed Gerck wrote:
>Stephen Kent wrote:
>>  Ed,
>>
>>  PKIX is winding down now; we are not taking on any new work items. I
>>  suspect that anything as basic as what you allude to would be a
>>  significant departure from what we have done, and thus is not
>>  appropriate for PKIX to pursue.
>
>Steve,
>
>How about a clarification to be added to the current PKIX documents
>that deal with revocation and validation of certs? This would help
>the weary reader, who must otherwise wade through this list's archives
>in order to find the limitations we have been discussing. For example
>(using some of your previous text):
>
>NOTE:
>  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. However, the ability of a RP to establish
>  the validity of a certificate is a function of the certificate path
>  that the RP uses to validate the certificate, and of the access to
>  revocation status information available to the RP. Since there may be
>  more than one path used to validate the same certificate, it is possible
>  to obtain different answers to the question whether a certificate is
>  valid, depending on which path the RP uses. Also, two RPs may have
>  access to different revocation status data for the EE certificate or for
>  a CA certificate along a path, so that each RP may arrive at a different
>  view of the validity of the EE certificate at any given time.
>
>  Moreover, in X.509/PKIX reliance terms, one may trust the confirmation
>  procedures of the issuer CA, the issuer CA Designated Responder or any
>  Trusted Responder during certificate reliance (i.e., whether the
>  certificate has been revoked or not) under CRLs or OCSPs, but one cannot
>  rely upon them for other than their value as a representation of the
>  issuer CA revocation management as expressed in the issuer CA own terms
>  and rules, usually contained in the CA CPS.
>
>Comments?
>
>Cheers,
>Ed Gerck

We have a suggestion before the WG to issue an update to 3280, so the 
WG can decide if text of the sort noted above should be part of the 
update, if we proceed on that work item.

With regard to the text above, I like the first paragraph :-), but 
the second one becomes murky very quickly. The paragraph doesn't 
convey any meaning to me.
It probably doesn't help that the paragraph is one, 6 line sentence, 
or that it introduces terms such as "CA Designated Responder," 
"Trusted Responder," ...

Steve