[x500standard] Re: Revocation list definitions
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>, "SG17-Q11" <T13sg17q11@xxxxxxxxxxxxx>
- Date: Fri, 25 Apr 2014 15:59:42 +0200
Hi,
David Cooper wrote:
"Contrary to what the defect report says, X.509 intentionally defined CRL to
include revocation lists that covered public-key certificates and revocation
lists that covered attribute certificates,"
I been holding DR_391 back for that reason. What comes from NIST, I take
seriously. I have now updated the DR to a more extensive discussion without
suggesting a resolution. Please comment on which way to go, as the answer is
not that obvious (see http://x500standard.com/uploads/Ig/DR_391.pdf).
I still need to address the concern about the issuingDistributionPoint
extension as raised by David.
Erik
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of David A. Cooper
Sent: Tuesday, January 28, 2014 3:48 PM
To: x500standard@xxxxxxxxxxxxx
Subject: [x500standard] Re: Revocation list definitions
On 01/28/2014 07:19 AM, Erik Andersen wrote:
Hi,
To separate PKI and PMI within X.509, I have made a proposal for updated
certificate revocation definitions.
Please comment!
Erik
Erik,
I am against this defect report as well. However, I've noticed a far more
serious problem. I see absolutely no reason to insist on a complete
separation between PKI and PMI, but it appears that non-backward compatible
changes have already been made to move in this direction. Contrary to what
the defect report says, X.509 intentionally defined CRL to include
revocation lists that covered public-key certificates and revocation lists
that covered attribute certificates, so it cannot be "clarified" to make it
clear that CRLs only cover public-key certificates. Even now there is still
text in X.509 that says otherwise:
The CRL distribution points extension shall be used only as a certificate
extension and may be used in authority-certificates, end-entity public-key
certificates, and in attribute certificates. This field identifies the CRL
distribution point or points to which a certificate user should refer to
ascertain if the certificate has been revoked. A certificate user can obtain
a CRL from an applicable distribution point or it may be able to obtain a
current complete CRL from the authority directory entry.
Note that the term "CRL" is used even though the extension may appear in
either a public-key or attribute certificate.
What I find very disturbing, however, is that I just noticed that the
definition of the issuingDistributionPoint extension has been changed
(without changing the OID). In the 4th edition it was defined as:
IssuingDistPointSyntax ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsAuthorityCerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
In the 6th edition it is defined as:
IssuingDistPointSyntax ::= SEQUENCE {
-- If onlyContainsUserPublicKeyCerts and onlyContainsCACerts are both
FALSE,
-- the CRL covers both certificate types
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserPublicKeyCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE }
RFC 5280 contains the definition from the 4th edition, and I don't see the
IETF updating RFC 5280 to change this. I don't know what (if any) other
non-backward compatible changes were made in X.509 as part of an effort to
"separate PKI and PMI within X.509," but making unnecessary non-backward
compatible changes like this to a stable standard can do nothing but cause
problems.
Dave
----- www.x500standard.com <http://www.x500standard.com> : The central
source for information on the X.500 Directory Standard.
Other related posts:
