Subject: CRL Issuer : 5 fixes

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 22 Jun 2005 13:23:46 +0100

Here is another attempt to fix the text. A rational has been added 
for each of the five fixes.

 FIX n°1. In section 4.2.1.14 CRL Distribution Points
 Change:

 If the certificate issuer is not the CRL
 issuer, then the cRLIssuer field MUST be present and contain the Name
 of the CRL issuer.

 into:

 If the certificate issuer is not issuing CRLs for that certificate, then the
 cRLIssuer field MUST be present and contain the Name of the CRL issuer.

 RATIONAL: A CA may wish to issues CRLs for some certificates, but also 
wish delegate this responsibility for some other certificates.

 FIX n°2. In section 5.2.5 Issuing Distribution Point

 Change:

 If the distributionPoint field is absent, the CRL MUST contain
 entries for all revoked unexpired certificates issued by the CRL
 issuer, if any, within the scope of the CRL.

 into:

 If the distributionPoint field is absent, the CRL MUST contain
 entries for all revoked unexpired certificates, if any, issued by
 the CA that delegated the publication of the CRL, within the scope
 of the CRL.

RATIONAL: The grammatical construction is ambiguous since it may be 
understood as "certificates issued by the CRL issuer". Certificates are 
issued by the CA that delegated the publication of the CRL.

 FIX n°3. In section 5.2.5 Issuing Distribution Point

 Change:

 The CRL issuer MUST assert the indirectCRL boolean, if the scope of
 the CRL includes certificates issued by authorities other than the
 CRL issuer.

 into:

 The CRL issuer MUST assert the indirectCRL boolean, if the scope of
 the CRL includes entries for certificates issued by more than one CA.

RATIONAL: The grammatical construction is ambiguous since it may be 
understood that CRL issuers issue certificate. It is simpler to say that 
indirect CRLs are for CRLs covering revocation status information issued 
by more than one CA.

 FIX n°4. In section 5.3.4 Certificate Issuer

 Change:

 If this extension is not present on the first entry in an
 indirect CRL, the certificate issuer defaults to the CRL issuer.

 into:

 If this extension is not present on the first entry in a CRL,
 then the CRL includes entries for certificates issued by a
 single CA.

RATIONAL: The current sentence is incorrect since the CRL 
issuer name may be different from the CA name and we may still have 
a CRL covering certificates issued by a single CA.

 FIX n°5. This last change proposal is not directly related to the
 vocabulary issue, but was noticed while re-reading section
 5.3.4 Certificate Issuer

 Change:

 If an implementation ignored this extension it could not
 correctly attribute CRL entries to certificates. This specification
 RECOMMENDS that implementations recognize this extension.

 into:

 A implementation SHALL reject the CRL, if this extension is
 encountered and is not recognized.

RATIONAL: The current text needs to be corrected since it does not 
comply with the normal behaviour for critical extensions

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 22 Jun 2005 10:02:56 -0400

Denis,

See my responses in [Santosh:].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, June 22, 2005 8:24 AM
To: pkix
Subject: CRL Issuer : 5 fixes

 If the certificate issuer is not the CRL
 issuer, then the cRLIssuer field MUST be present and contain the Name  of
the CRL issuer.

 into:

 If the certificate issuer is not issuing CRLs for that certificate, then
the  cRLIssuer field MUST be present and contain the Name of the CRL issuer.

[Santosh: I am ok with this change.]

 Change:

 If the distributionPoint field is absent, the CRL MUST contain  entries for
all revoked unexpired certificates issued by the CRL  issuer, if any, within
the scope of the CRL.

 into:

 If the distributionPoint field is absent, the CRL MUST contain  entries for
all revoked unexpired certificates, if any, issued by  the CA that delegated
the publication of the CRL, within the scope  of the CRL.

[Santosh: I strongly disagree since there may not be a delegation involved.
The CRL may be partitioned for reason code and/or for entity type.  The
current text should be left or revised to:  "If the distributionPoint field
is absent, the CRL MUST contain  entries for all revoked unexpired
certificates covered by the CRL  issuer, within the scope of the CRL."]

 Change:

 The CRL issuer MUST assert the indirectCRL boolean, if the scope of  the
CRL includes certificates issued by authorities other than the  CRL issuer.

 into:

 The CRL issuer MUST assert the indirectCRL boolean, if the scope of  the
CRL includes entries for certificates issued by more than one CA.

[Santosh: I strongly disagree since a single CRL issuer could be indirect
CRL issuer for one CA only.  The current text should be left or revised to
the following to replace authorities with CAs:  "The CRL issuer MUST assert
the indirectCRL boolean, if the scope of the CRL includes certificates
issued by CAs other than the  CRL issuer."]

 Change:

 If this extension is not present on the first entry in an  indirect CRL,
the certificate issuer defaults to the CRL issuer.

 into:

 If this extension is not present on the first entry in a CRL,  then the CRL
includes entries for certificates issued by a  single CA.

[Santosh: This is downright wrong.  If you want to further clarify what is
being said, a minor change to clarify that the statement applies to the
first entry can be made as follows: "If this extension is not present on the
first entry in an indirect CRL, the certificate issuer for the first entry
defaults to the CRL issuer.]

 FIX n°5. This last change proposal is not directly related to the
vocabulary issue, but was noticed while re-reading section  5.3.4
Certificate Issuer

 Change:

 If an implementation ignored this extension it could not  correctly
attribute CRL entries to certificates. This specification  RECOMMENDS that
implementations recognize this extension.

 into:

 A implementation SHALL reject the CRL, if this extension is  encountered
and is not recognized.

[Santosh: I am ok with the change.]

Denis

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 29 Jun 2005 18:45:02 -0400

Denis,

I am very tempted to start throwing all messages from you into the trash 
unread.  Your  continuous posting of the same lies over and over again 
is getting ridiculous.  You made these claims about indirect CRLs on the 
PKIX list last November.  They were discussed at length at that time.  
You then started all over again by repeating these same false statements 
on the X.500 mail list, where they were again discussed at length and 
where again several people explained to you that you were wrong.  At no 
point has anyone ever supported you claim that a CRL should be treated 
as an indirect CRL (i.e., the indirectCRL flag set and the 
certificateIssuer CRL entry extension used) when the CRL covers more 
than one CA.  Everyone has repeatedly informed you that a CRL is an 
indirect CRL (i.e., the indirectCRL flag MUST be set) if the CRL covers 
certificates issued by an entity other than the issuer of the CRL, even 
if the CRL only covers certificates issued by a single CA.

Despite these lengthy discussions in November on both the PKIX and X.500 
mail lists.  Despite your not being able to find anyone who agrees with 
your statements and despite your not being able to point to any text in 
either X.509 or RFC 3280 to support your claims, you are now making the 
same claims again as if they had never been discussed previously on the 
list.  And despite all of these previous discussions, you try to suggest 
that the changes you propose below are merely clarifications.  Given the 
length at which these claims have already been discussed, I find it 
impossible to believe that you think these are simply clarifications 
rather than semantic changes.

>wish delegate this responsibility for some other certificates.
This is incorrect.  Just because a certificate includes a 
cRLDistributionPoints extension that includes a distribution point with 
cRLIssuer present does not necessarily mean that the certificate issuer 
is not issuing CRLs for that certificate.  It simply means that there is 
a CRL issued by an entity other than the certificate issuer that covers 
the certificate.   This does not preclude the possibility that there is 
another CRL issued by the certificate issuer that also covers the 
certificate.

>issued by the CA that delegated the publication of the CRL.
The original sentence is not incorrect.  If a CA issues a CRL that does 
not include a distributionPoint field, that CRL MUST cover all 
certificates issued by that CA (except as limited by 
onlyContainsCACerts, onlyContainsUserCerts, etc.).  If the indirectCRL 
flag is set, then the CRL may also covers certificates issued by other 
CAs.  Of course, if the issuer of the CRL is not a CA (i.e., it does not 
issue certificates), then the statement is still true since the CRL will 
trivially provide status information for all certificates issued by the 
CRL issuer.

>indirect CRLs are for CRLs covering revocation status information issued 
If a CRL covers certificates for which the issuer field in the 
certificate is different from the issuer field in the CRL, then the 
indirectCRL flag MUST be set to TRUE, even if the CRL only covers 
certificates issued by a single CA.

>a CRL covering certificates issued by a single CA.
The original sentence is correct and your sentence is an attempt to 
significantly change the rules for indirect CRLs.  See the archives from 
November.

>comply with the normal behaviour for critical extensions
You are taking this out of context:  The preceding sentence says: "If 
used by conforming CRL issuers, this extension MUST always be 
critical."  The sentence that follows, "If an implementation ignored 
this extension...."), explains the reason that the extension MUST be 
critical.