Subject: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is available

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Jul 2005 22:44:40 +0100

Making a comparison between this draft and RFC 3280bis I noticed that
this draft has the same problem as previous drafts.

This draft contains a complete rewrite of RFC 3280 section 6.3 and as
such almost none of the changes are supported by any explanation or
motivation provided in the draft.

Current text in RFC 3280, which the current editorial process works
from, is a result of a long consensus process. To adopt a complete
rewrite would require a very long and painful process of making sure
that no new problems are introduced. In fact many such problems can
easily be located and there may be many more.

I suggest once again that the RFC 3280bis editorial process disregard
from this draft and that PKIX chairs instead ask the author to come up
with a specific list of numbered issues, each accompanied by proposed
resolutions and appropriate motivation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 21 juli 2005 07:27
> To: pkix
> Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available
> 
> 
> <draft-pinkas-pkix-conf-crl-validation-02.txt> is now available at:
>
http://www.ietf.org/internet-drafts/draft-pinkas-pkix-conf-crl-validatio
n-
> 02.txt
> 
> There is a common section for any kind of CRL.
>  See section 6.3.3.1  CRL Processing start for all applications
> 
> Note that "old CRLs" may be selected in that phase and this may be
quite
> useful,
> if it can be found that the target certificate was already revoked
some
> time ago.
> Note also that more than one CRL may be found in the local cache.
> The current algorithm does not support these cases because it is
making
> incorrect-different-others assumptions.
> 
> Then the document makes a clear distinction between three kinds of
> processing
> where the complexity goes from simple to complex:
> 
> 1 - What conformant applications shall support. This covers CRLs that
> contain certificates
>     from a single CA. The CRL may be issued by the CA or by a CRL
issuer
> (that is not a CA)
>     designated by a CA.
> 
>     See section 6.3.3.2  CRL Processing for conforming applications.
> 
> 2 - If an application supports Certificate Issuer CRL entry
extensions,
> then this section applies.
>     This covers CRLs that *may* contain certificates from more than
one
> CA.
> 
>     See section 6.3.3.3. CRL Processing for applications supporting
>     Certificate Issuer CRL entry extensions.
> 
> 3 - If an application supports delta-CRLs. I have left the details for
> David Copper
>     who is much more expert than I am on that topic.
> 
>     See the nearly empty section 6.3.3.4. CRL Processing for
applications
> supporting delta CRLs.
> 
> Note : Santosh, please read section 6.3.3.3. and you will see that it
is
> possible
>           to go backwards looking for Certificate Issuer CRL entry
> extensions.
> 
> Denis
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 22 Jul 2005 11:18:39 +1000

Denis,
By ignoring the IDP.indirectCRL flag your rules can give the wrong result by accepting a CRL that does not apply to a given certificate.
 
Consider a certificate that has a CRL-DP extension with a cRLIssuer field and consider a CRL without an IDP extension from that cRLIssuer.  Your rules say that the CRL covers the certificate (ie would list the certificate if it was revoked), but it does not cover it.  The CRL (without IDP) only covers certificates issued by the authority that issued the CRL.

Only when IDP.indirectCRL is true must the CRL issuer "ensure that the CRL is complete in that it contains all revocation entries ... from all authorities that identify this CRL in their certificates" [X.509, 8.6.2.2 IDP extension].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 22 July 2005 12:27 AM
To: pkix
Subject: draft-pinkas-pkix-conf-crl-validation-02.txt is available

---

From: "Denis Pinkas" <[email-masked]>
Date: Fri, 22 Jul 2005 16:30:09 +0100

James,

>By ignoring the IDP.indirectCRL flag your rules can give the wrong result 
>by accepting a CRL that does not apply to a given certificate.

If the CRL issuer is only "working" on behalf of a single CA, I do not think so.
Otherwise, would you provide an example where the result would be wrong ?
 
>Consider a certificate that has a CRL-DP extension with a cRLIssuer field 
>and consider a CRL without an IDP extension from that cRLIssuer.  

>Your rules say that the CRL covers the certificate (ie would list the certificate 
>if it was revoked), but it does not cover it.  The CRL (without IDP) only covers 
>certificates issued by the authority that issued the CRL.

Here are some extracts from 3280bis :

Page 51:

   CRL issuers issue CRLs.  The CRL issuer is either the CA or an entity
   that has been authorized by the CA to issue CRLs.  

Page 62:

   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.

Your comment applies since the only case where a CRL issuer 
may issue certificates is when it is also a CA.

This sentence then mandates CRL Issuers to support the distributionPoint 
field present.

However from a RP point of view, in the case the CRL contains certificates 
from a single CA, if this field is present *but no test is made on it*, would you 
be able to provide an example where the algorithm would give the wrong result  ?

>Only when IDP.indirectCRL is true must the CRL issuer "ensure that 
>the CRL is complete in that it contains all revocation entries ... from all 
>authorities that identify this CRL in their certificates" [X.509, 8.6.2.2 IDP extension].

The word 'issuer' is missing. The exact sentence is:

If indirectCRL is true, [..] it is the responsibility of the CRL issuer to ensure that 
the CRL is complete in that it contains all revocation entries […] from all authorities 
that identify this CRL *issuer* in their certificates.

Denis

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 22 Jul 2005 17:51:04 +0100

> from a single CA, if this field is present *but no test is made on
it*,
> would you

Yes,

Consider a CA that provides partitioned CRLs where each CRL only covers
a limited number of the issued certificates. This could be partitioned
by issuing key, serial number range, certificate policy or anything
(except reason code).

I now rename one of the CRLs that does NOT cover my revoked certificate
and manage to replace it with the one that would indicate that my
certificate is revoked.

Since you don't check the IDP you will miss the fact that the CRL has
been renamed and replaced and you will accept my certificate as valid.

So you have now completely changed the trust model to force the RP to
trust the directory to provide the correct partitioned CRL. This is a
severe security flaw.

Stefan Santesson

> Sent: den 22 juli 2005 08:30
> To: pkix; Manger, James H
> Subject: Re: RE: draft-pinkas-pkix-conf-crl-validation-02.txt is
available
> >if it was revoked), but it does not cover it.  The CRL (without IDP)
only
> covers
> from a single CA, if this field is present *but no test is made on
it*,
> would you
> >the CRL is complete in that it contains all revocation entries ...
from
> all
> >authorities that identify this CRL in their certificates" [X.509,
8.6.2.2
> IDP extension].
> If indirectCRL is true, [..] it is the responsibility of the CRL
issuer to
> ensure that
> the CRL is complete in that it contains all revocation entries [...]
from
> all authorities

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 26 Jul 2005 16:13:07 +0100

Stefan,

>> However from a RP point of view, in the case the CRL contains
>> certificates from a single CA, if this field is present *but no test is made on it*,
>> would you be able to provide an example where the algorithm would give 
>> the wrong result  ?

>Yes,

Great ! Let us see.

>by issuing key, serial number range, certificate policy or anything

The simple case applies when the CRL IDP extension is NOT supported by the RP. 
Partitioned CRLs mandate the presence of the CRL IDP extension.

Thank you for trying.

Denis