Internet DRAFT - draft-pinkas-pkix-conf-crl-validation
draft-pinkas-pkix-conf-crl-validation
Network Working Group D.Pinkas(Bull)
INTERNET-DRAFT July 2005
Expires January 2006
Target Category: not intended to be published as an RFC
Conforming CRL validation for relying parties
<draft-pinkas-pkix-conf-crl-validation-02.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The text currently present in section 6.3 from RFC 3280 is dedicated
to CRL validation. This text needs to be more detailed to explain
exactly how it can made be sure that a CRL is issued by the right
entity. In addition, a text dedicated to the characteristics that
conforming applications MUST support needs to be provided: the
current text covers the most complex case and is too complicated to
be easily simplified. Text is proposed to be included in 3280bis
and to partially replace section 6.3 .
Pinkas [Page 1]
INTERNET DRAFT CRL Validation July 2005
1. Introduction
Section 6.3 from RFC 3280 [1] covers many features that are not
required to be supported by conforming relying party applications.
According to section 5, conforming applications are NOT REQUIRED to
support processing of delta CRLs, or CRLs with a scope other than
all certificates issued by one CA.
According to section 5.2.5, conforming implementations are NOT
REQUIRED to support the CRL Issuer Distribution Point extension
(IDP) that MAY be present in a CRL.
According to section 4.2.1.14, this profile RECOMMENDS to support
the CRL distribution points extension. So the two cases where this
extension is present and not present need to be covered.
Its also currently unclear to know which key shall be used to verify
a CRL and how it can be made sure that this key is the right one.
The current text which covers the most complicated case should be
reviewed and aligned with the proposed text since it contains many
points to be fixed (e.g. incorrect initial variables, insufficient
output variables, insufficient tests, etc ...).
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in RFC 2119 [STDWORDS]
2. Scope
The text below is a proposal to clarify the above issues. The
section numbering of RFC 3280 has been kept below. The next
section of this document (i.e. Security considerations )is numbered
section 3.
The proposed text is as follows:
6.3 CRL Validation
This section describes the steps necessary to determine if a
certificate is not revoked, revoked, or revoked with an on hold
status when CRLs are the revocation mechanism used by the
certificate issuer.
Conforming applications are NOT REQUIRED to support processing of
delta CRLs, or CRLs with a scope other than all certificates issued
by one CA.
Pinkas [Page 2]
INTERNET DRAFT CRL Validation July 2005
According to section 5.2.5, conforming implementations are NOT
REQUIRED to support the Issuer Distribution Point extension (IDP)
that MAY be present in a CRL.
According to section 4.2.1.14, this profile RECOMMENDS to support
the CRL distribution points extension. So the two cases where this
extension is present and not present are covered.
Conforming implementations that support CRLs are not required to
implement this algorithm, but they MUST be functionally equivalent
to the external behavior resulting from this procedure. Any
algorithm may be used by a particular implementation so long as it
derives the same result.
This algorithm assumes that a certification path has already been
constructed and that it is only needed to verify that none of the
certificates from that revocation path is revoked.
In order to simplify the description, the algorithm focuses on
the last certificate from the certification path, called the target
certificate, but the same checks MUST be done on every certificate
from the certification path.
This algorithm assumes that all of the available CRLs are
accessible in a local cache, whether or not CRL DP extensions have
been used to fetch them. Further, if the next update time of a CRL
has passed, the algorithm assumes that a mechanism to fetch a
current available CRL, if any is available , and place it in the
local CRL cache is existing.
This algorithm defines a set of inputs, a set of state variables, and
processing steps that are performed for each certificate in the path.
The algorithm output is the revocation status of the certificate and,
if indicated, the revocation reason.
In order to simplify the description of the algorithm, the
description is first limited to the case of conforming applications.
These applications do NOT need to support processing of delta CRLs,
indirect CRLs, or CRLs with a scope other than all certificates
issued by one CA, nor to support the processing of the Issuer
Distribution Point extension (IDP) from CRLs.
6.3.1 Revocation Inputs
To support revocation processing, the algorithm requires two inputs:
(a) the target certificate. The basicConstraints extension is
used to determine whether the supplied certificate is associated
with a CA or an end entity.
Pinkas [Page 3]
INTERNET DRAFT CRL Validation July 2005
Note that implementations supporting legacy PKIs, such as RFC
1422 and X.509 version 1, will need an additional input
indicating whether the supplied certificate is associated with
a CA or an end entity.
(b) certificates from the certification path: all the
certificates from the certification path to be validated MUST
be known.
6.3.2 Initialization and Revocation State Variables
To support CRL processing, the algorithm requires the following two
state variables:
(a) cert_revoc_status: This variable contains the revocation
status of the certificate. This variable may be assigned one of
the following three values: REVOKED, NOT_REVOKED or UNKNOWN.
This variable is initialized to UNKNOWN.
(b) revoc_reason: This variable contains the revocation reason.
This variable is initialized to an empty value.
6.3.3 CRL Processing
This algorithm begins by assuming that the revocation status of the
target certificate is UNKNOWN. The algorithm checks one or
more CRLs until either the certificate revocation status is
determined, if possible, to be REVOKED or NOT_REVOKED.
6.3.3.1 CRL Processing start for all applications
It is first necessary to select a candidate CRL and then verify
that this CRL is adequate for the target certificate.
The candidate CRL MUST first be selected in the following way:
(a) If the target certificate does not include a CRL DP
extension, then the candidate CRL MUST have the following
properties:
(1) The issuer field from the CRL MUST be identical to the
issuer field from the target certificate.
(2) The signature from the CRL MUST be verified using an
issuing key from the CA that has issued the target
certificate.
Pinkas [Page 4]
INTERNET DRAFT CRL Validation July 2005
NOTE: This key may be the same key as the key used to
issue the target certificate, but it may be a different
key. In the later case, the same sequence of CA DNs,
up to the same trust anchor, MUST be used.
(3) The thisUpdate field from the CRL MUST be both greater
than the notBefore field from the validity field of the
target certificate and smaller than the notAfter field
from the validity field of the target certificate. If
several CRLs in the local cache satisfy these conditions,
then the CRL that has the thisUpdate field closest to the
current time SHALL be chosen.
(b) If the target certificate includes a CRL DP extension with
the cRLIssuer field present, then the candidate CRL MUST
have the following properties:
(1) The issuer field from the CRL MUST be identical to one
of the values contained the cRLIssuer field from CRL DP
extension of the target certificate.
(2) A CRL Issuer certificate issued by the same CA that has
issued the target certificate MUST be found. That
certificate MUST have the cRLSign bit set, and MUST
include in its subject field the same DN as the one
of the DNs present in the crLIssuer field and MUST be
within its validity period.
NOTE: The key used to sign the CRL Issuer certificate
may be the same key as the key used to issue the target
certificate, but it may be a different key. In the
later case, the same sequence of CA DNs, up to the same
trust anchor, MUST be used.
(3) The signature from the CRL MUST be verified using the
key found in the subjectPublicKeyInfo field from the
CRL Issuer certificate.
(4) The thisUpdate field from the CRL MUST be both greater
than the notBefore field from the validity field of the
target certificate and smaller than the notAfter field
from the validity field of the target certificate. If
several CRLs in the local cache satisfy these conditions,
then the CRL that has the thisUpdate field closest to the
current time SHALL be chosen.
If no CRL has the above properties, then the variables keep their
initial values and the algorithm terminates.
6.3.3.2 CRL Processing for conforming applications
If one CRL with the above properties may be found, then look for
a CRL entry where the userCertificate field matches the certificate
serial number of the target certificate :
Pinkas [Page 5]
INTERNET DRAFT CRL Validation July 2005
(a) if such an entry is found, then make sure that this CRL
entry does not include a CRL entry extension that is
critical and not recognized and then set the
cert_revoc_status variable to REVOKED. In that
case, if the CRL entry extension " reasonCode " is
present in that CRL entry, then set the revoc_reason
variable to the value contained in that CRL entry
extension and the algorithm terminates.
NOTE: if that CRL entry includes a CRL entry extension
that is critical and not recognized, then the CRL SHALL
be discarded, the variables keep their initial values
and the algorithm terminates.
(b) if such an entry cannot be found, then check if the
nextUpdate field is less than the current time and,
if this is the case, then set the cert_revoc_status
variable to UNKNOWN and the algorithm terminates;
otherwise set the cert_revoc_status variable to
NOT_REVOKED and the algorithm terminates.
6.3.3.3. CRL Processing for applications supporting Certificate
Issuer CRL entry extensions
Conforming applications are NOT REQUIRED to support the issuing
distribution point extension (IDP) which is a critical CRL extension.
As a consequence they are NOT REQUIRED to support the indirectCRL
boolean from the IDP extension that indicates that the scope of the
CRL includes certificates issued by more than one authority.
However, the following applies when the IDP extension is present
and the indirectCRL boolean is set to TRUE. In such a case the CRL
will contain one or more certificate issuer CRL entry extension.
If one CRL with the properties from section 6.3.3.1 has been found,
then the following applies :
Look for one or more CRL entry where the userCertificate field
matches the certificate serial number of the target certificate.
If no entry can be found, then check if the nextUpdate field
is less than the current time and, if this is the case, then
set the cert_revoc_status variable to UNKNOWN and the
algorithm terminates; otherwise set the cert_revoc_status
variable to NOT_REVOKED and the algorithm terminates.
If one or more entry can be found, then, for each found entry,
check if the entry contains a Certificate Issuer CRL entry
extension :
(1) If it does, then check if its content matches the
content of the issuer field of the target certificate.
Pinkas [Page 6]
INTERNET DRAFT CRL Validation July 2005
- If it does, then set the cert_revoc_status variable
to REVOKED and if the CRL entry extension "reasonCode"
is present in that CRL entry, then set the
revoc_reason variable to the value contained in that
CRL entry extension and the algorithm terminates.
- If it does not, then :
(i) check if there exists a previous CRL entry:
- If there is no previous CRL entry, then
this is an error in the structure of the
CRL and the algorithm terminates.
- otherwise check if that CRL entry contains
a Certificate Issuer CRL entry extension :
- If it does, then check if its content
matches the content of the issuer field
of the target certificate.
- If it does, then set the
cert_revoc_status variable to
REVOKED and if the CRL entry
extension "reasonCode" is present in
that CRL entry, then set the
revoc_reason variable to the value
contained in that CRL entry extension
and the algorithm terminates.
- If it does not, and if each found
entry has been processed, then set
the cert_revoc_status variable to
NOT_REVOKED and the algorithm
terminates.
- If it does not, then proceed with (i).
(2) If it does not, then proceed with (i).
6.3.3.4. CRL Processing for applications supporting delta CRLs
Conforming applications are NOT REQUIRED to support delta CRLs.
However, for applications supporting delta CRLs, as well as the
previous features, the following applies:
[Text to be provided, e.g. by David Cooper]
Pinkas [Page 7]
INTERNET DRAFT CRL Validation July 2005
3 Security considerations
1. A CA is free to allocate the DN of an entity as it wishes. Therefor
name collision may happen: the same DN, as assigned by two different
CAs, may designate two different entities. Name collision between
CA names is a particular concern and the proposal takes care of
such a issue, if an additional requirement that applies to CRL
Issuers issuing indirect CRLs (and which is currently not present)
in RFC 3280 is added.
A CRL Issuer is delegated the responsibility to generate and
publish the revocation status information for the certificates
issued by a CA by accepting this duty and by receiving a CRL Issuer
certificate from the CA that delegated that responsibility. The CRL
Issuer name will be assigned by the CA and name collision between
CRL Issuer names is not an issue.
However, a CRL Issuer shall not accept this duty, if it already
agreed to perform that task for another CA that has the same DN.
This avoids the possible confusion between CA names that may be
contained in the Certificate Issuer CRL entry extension from an
indirect CRL.
2. RFC 3280 is dedicated to the case where CRL Issuer receives the
delegation to generate and issue certificate revocation information
from CAs.
The OCSP model recognizes another case, where the relying party is
directly trusting a given OCSP responder independently of what CAs
are saying.
In the same way, a model where an entity is directly trusted by
some relying parties, for some kind of certificates, to issue CRLs
for some CAs, could exist, but that model is not supported nor
described in RFC 3280.
In such an hypothetical case, the current CRL structure of an
indirect CRL might be used, provided that additional local trust
conditions are defined in a validation policy. Such definitions
are outside the scope of RFC 3280.
4. IANA Considerations
Not applicable
5. References
5.1 Normative references
[1] IETF RFC 3280 (2002): "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile".
Pinkas [Page 8]
INTERNET DRAFT CRL Validation July 2005
[STDWORDS] IETF RFC 2119 Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2
5.2 Informative references
None.
6. Authors' address
Denis Pinkas
Bull S.A.
Rue Jean-Jaures
78340 Les Clayes sous Bois CEDEX
FRANCE
EMail: Denis.Pinkas@bull.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer
This document and the information contained herein are provided on
An "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Pinkas [Page 9]
INTERNET DRAFT CRL Validation July 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Pinkas [Page 10]
