IETF Logo Mail Archive

[pkix] How to handle sequence of distributionPoint's

Petr Pisar <petr.pisar@atlas.cz> Mon, 05 October 2009 15:19 UTC

Return-Path: <petr.pisar@atlas.cz>
X-Original-To: pkix@core3.amsl.com
Delivered-To: pkix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263AB3A6A05 for <pkix@core3.amsl.com>; Mon, 5 Oct 2009 08:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.838
X-Spam-Level:
X-Spam-Status: No, score=-3.838 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_INA=0.786]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fS5DHNb-Gne for <pkix@core3.amsl.com>; Mon, 5 Oct 2009 08:19:23 -0700 (PDT)
Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by core3.amsl.com (Postfix) with ESMTP id 1DD373A6926 for <pkix@ietf.org>; Mon, 5 Oct 2009 08:19:21 -0700 (PDT)
Received: from dior.ics.muni.cz (dior.ics.muni.cz [147.251.6.10]) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id n95FKs5H018949 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <pkix@ietf.org>; Mon, 5 Oct 2009 17:20:55 +0200
Received: from album.ics.muni.cz (album.ics.muni.cz [147.251.23.20]) by dior.ics.muni.cz (8.13.8+Sun/8.13.8) with SMTP id n95FKr1p009300 for <pkix@ietf.org>; Mon, 5 Oct 2009 17:20:53 +0200 (CEST)
Received: by album.ics.muni.cz (sSMTP sendmail emulation); Mon, 05 Oct 2009 17:20:53 +0200
Date: Mon, 05 Oct 2009 17:20:53 +0200
From: Petr Pisar <petr.pisar@atlas.cz>
To: pkix@ietf.org
Message-ID: <20091005152052.GA23289@album.bayer.ipv6ia.org>
Mail-Followup-To: pkix@ietf.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Muni-Spam-TestIP: 147.251.6.10
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Mon, 05 Oct 2009 17:20:55 +0200 (CEST)
Subject: [pkix] How to handle sequence of distributionPoint's
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2009 15:22:02 -0000

Hello,

I read RFC 3280 (Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile) carefully and I'm not sure how
should application check certificate validity if there is more than one
DistributionPoint. Should application fetch CRLs from all DistributionPoint's
and check certificate against them, or one successfull DistributionPoint is
enough?

I understand situation with one DistributionPoint having more GeneralName's.
RFC states explicitly that such GenerlName's are equivalent. However RFC does
not say anything about multiple DistributionPoint's each having only one
GeneralName.

I think that multiple DistributionPoint's are designed for collection of
incomplete CRLs, thus application should check all of them. However there is
no clarification in given RFC.

And to get sharper edge, what's desired behaviour when all DistributionPoint's
have no reasons flag? I think there is no way how to signal to appliaction the
CRLs are partitioned on some internal organisation reasons (e.g. one CRL for
CA certificates only, another CRL for end user not-CA certficates), thus
appliaction should check all of them.

What's correct procedure?

-- Petr Pisar

v2.23.0 | Report a Bug | By Email