Subject: RE: CRL Issuer : 5 fixes

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 30 Jun 2005 13:39:54 +0100

I support David's arguments to reject these change proposals, which are not just clarifications but in many cases do change semantics incorrectly.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of David A. Cooper
> Sent: den 30 juni 2005 00:45
> To: Denis Pinkas
> Cc: pkix
> Subject: Re: CRL Issuer : 5 fixes
> 
> 
> 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.
> 
> Denis Pinkas wrote:
> 
> >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.
> >
> >
> 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.
> 
> > 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.
> >
> >
> 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.
> 
> > 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.
> >
> >
> 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.
> 
> > 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.
> >
> >
> The original sentence is correct and your sentence is an attempt to
> significantly change the rules for indirect CRLs.  See the archives from
> November.
> 
> > 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
> >
> >
> 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.
> 
>