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

"Santosh Chokhani" <chokhani@orionsec.com> Tue, 06 April 2004 19: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 PAA16474 for <pkix-archive@lists.ietf.org>; Tue, 6 Apr 2004 15:09:27 -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 i36HuWLC067475; Tue, 6 Apr 2004 10:56:32 -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 i36HuW87067474; Tue, 6 Apr 2004 10:56:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i36HuVhD067468 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 10:56:31 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i36HuYAt027271 for <ietf-pkix@imc.org>; Tue, 6 Apr 2004 13:56:34 -0400
From: Santosh Chokhani <chokhani@orionsec.com>
To: ietf-pkix@imc.org
Subject: RE: clarification proposal -- Re: Current status of CRL validation ?
Date: Tue, 06 Apr 2004 13:56:34 -0400
Message-ID: <009f01c41c00$8049e280$9a00a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p06020405bc9860671a8f@[128.89.89.75]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i36HuVhD067469
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>
Content-Transfer-Encoding: 8bit

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.

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On
Behalf Of Stephen Kent
Sent: Tuesday, April 06, 2004 9:31 AM
To: Ed Gerck
Cc: ietf-pkix@imc.org
Subject: Re: clarification proposal -- Re: Current status of CRL validation
?



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