Subject: [pkix] question about CRL's scope

From: Zhuxian <[email-masked]>
Date: Tue, 10 May 2011 08:11:45 +0000

In 5280,   4.2.1.13.  CRL Distribution Points, it mentions that

This profile
   RECOMMENDS against segmenting CRLs by reason code.  When a conforming
   CA includes a cRLDistributionPoints extension in a certificate, it
   MUST include at least one DistributionPoint that points to a CRL that
   covers the certificate for all reasons.

But it also mentions as following:

   Each CRL has a particular scope.  The CRL scope is the set of
   certificates that could appear on a given CRL.  For example, the
   scope could be "all certificates issued by CA X", "all CA
   certificates issued by CA X", "all certificates issued by CA X that
   have been revoked for reasons of key compromise and CA compromise",
   or a set of certificates based on arbitrary local information, such
   as "all certificates issued to the NIST employees located in
   Boulder".

I am confused about these statements. Does it mean that CRL should not be segmented by reason, but it can be segemented by other mechnism?

And when it is segemented by other mechnism, it must include one full CRL also?

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 10 May 2011 08:20:17 -0400

The way I understand it is CRL segmentation is supposed to support efficiencies for the relying party, so that a constrained RP won't have to download a complete (potentially large) CRL in order to perform a validation.  However, to make this work the RP needs to know *in advance* which CRL segment to request; therefore CRL segmentation should be deterministic.  Segmentation by reason code is non-deterministic; the RP has no clue why the cert might be revoked, and so will always have to download *all* segments to get an answer, mooting all the benefit of segments.

You can segment deterministically by data that exists in the cert: DN component, serial number, validity dates, keyUsage, EKU, SANs, or other extensions; but not by data that exists only in the CRL: reason code, revocation date, etc.

That said, not all RPs support segmented CRLs (they're optional) so a CA must always produce an unsegmented CRL to support those RPs.  If your PKI is entirely internal, you can do whatever you want, but I wouldn't recommend it--no PKI stays internal forever.

-- T

On May 10, 2011, at 3:11 AM, Zhuxian wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 10 May 2011 11:24:27 -0400

In addition, note that the CRL partitioning could be stochastic and/or dynamic.

Stochastic in the sense that the rules could be simply random partitioning.

Dynamic in the sense that during a CA's life, the CA can change the rules for partitioning for yet to be issued certificates.

All of this is feasible and secure since the relying party simply matches the DP asserted in the CDP of a certificate to the DP asserted in the IDP of the CRL to ensure that it has the correct partition; the relying party need not know the logic for partitioning.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, May 10, 2011 8:20 AM
To: Zhuxian
Cc: [email-masked]
Subject: Re: [pkix] question about CRL's scope

-- T

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 May 2011 19:02:44 +0200 (MEST)

Miller, Timothy J. wrote:
> 
> The way I understand it is CRL segmentation is supposed to support
> efficiencies for the relying party, so that a constrained RP won't have
> to download a complete (potentially large) CRL in order to perform a
> validation.  However, to make this work the RP needs to know *in
> advance* which CRL segment to request; therefore CRL segmentation should
> be deterministic.  Segmentation by reason code is non-deterministic; the
> RP has no clue why the cert might be revoked, and so will always have to
> download *all* segments to get an answer, mooting all the benefit of
> segments.

CRL segmentation by reason code is pure and unnecessary bloat.

Which of the CRL reason codes:

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

is so utterly insignificant that an RP wants to consciously ignore
such a revocation when doing revocation checking, and at the same
time this reasonCode most be so extremely common that the huge amount
of saved bandwidth makes up for a 4x increase in code complexity.

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 May 2011 12:49:35 -0400

The original purpose of segmentation by reason code was to allow a
time/size tradeoff.  Revocation due to key compromise was deemed more
serious than revocation for other reasons, yet key compromise accounts
for a negligible volume of revocations.  So if relying parties wanted to
know about compromises within an hour but revocation for other reasons
could wait for a week, then the nearly-always empty CKL could be
downloaded hourly at little cost without also needing to download a huge
all-reasons CRL.

If there is no business need to prioritize by revocation reason, then
there is no need for technical mechanisms to support differentiated QoS.
The profile RECOMMENDS against segmenting by reason code based on an
assumption that Internet RPs will have equal timeliness requirements for
all reasons. 

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Miller, Timothy J.
Sent: Tuesday, May 10, 2011 8:20 AM
To: Zhuxian
Cc: [email-masked]
Subject: Re: [pkix] question about CRL's scope

You can segment deterministically by data that exists in the cert: DN
component, serial number, validity dates, keyUsage, EKU, SANs, or other
extensions; but not by data that exists only in the CRL: reason code,
revocation date, etc.

That said, not all RPs support segmented CRLs (they're optional) so a CA
must always produce an unsegmented CRL to support those RPs.  If your
PKI is entirely internal, you can do whatever you want, but I wouldn't
recommend it--no PKI stays internal forever.

-- T

On May 10, 2011, at 3:11 AM, Zhuxian wrote:

> I am confused about these statements. Does it mean that CRL should not
be segmented by reason, but it can be segemented by other mechnism?

---

From: Tom Gindin <[email-masked]>
Date: Tue, 10 May 2011 20:11:25 -0400

Zhuxian:

        You can use the Distribution Point as a partition identifier, and 
label the certificates belonging to a given partition by putting that 
value into CRLDistributionPoints while labelling the CRL using 
IssuingDistributionPoint.  A simple scheme, which many CA implementors 
would use, is to assign a base partition name to each partition, putting 
an HTTP URL of the form http://(host)/(CRLDir)/(partname).crl into CRLDP, 
and use the value (partname) as the CN attribute of any directory names in 
an LDAP or directory name DistributionPoint in CRLDP.
        I would probably be remiss not to point out that LDAP 
DistributionPoints interoperate far better beyond a single organization 
than directory name ones do, although not usually as well as HTTP ones.

                Tom Gindin
P.S. - The opinions above are mine, and not necessarily those of my 
employer.

From:   Zhuxian <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   05/10/2011 04:23 AM
Subject:        [pkix] question about CRL's scope
Sent by:        [email-masked]

This profile

I am confused about these statements. Does it mean that CRL should not be 
segmented by reason, but it can be segemented by other mechnism?

And when it is segemented by other mechnism, it must include one full CRL 
also?

---

From: Zhuxian <[email-masked]>
Date: Wed, 11 May 2011 05:08:54 +0000

Thank u all for the reply.

Now I am clear why partition CRL by reason code is not RECOMMEND by this profile. 

However, as it is just not RECOMMEND, 5280 still support reason code based partition in the CRL processing algorithm.

To develop a RP supporting 5280 compliant PKI, it should also implement the reason code logic.

And i still have some question about this feature.

1. If conforming CAs implement partion CRL, does it mean it MUST include CDP and use the DP to point to the CRL segment?
     Otherwise, only out-of-band mechnism can be used to get the corresponding CRL segment and the security issue (such as to check the CRL is really the segment matched the certificate) should also be handled out-of-band.

2. For reason code handling, 

For the CRL Distribution Points, in 4.2.1.13, it mentions as following:
  If the DistributionPoint omits the reasons field, the CRL MUST
   include revocation information for all reasons. 

For the IDP in CRL, in 5.2.5, it mentions as following:
   If onlySomeReasons does not appear,
   the distribution point MUST contain revocations for all reason codes.   

However, in the 6.3.3 CRL processing algorithm, 
  (d)  Compute the interim_reasons_mask for this CRL as follows:
        (2)  If the IDP CRL extension includes onlySomeReasons but the
              DP omits reasons, then set interim_reasons_mask to the
              value of onlySomeReasons in the IDP CRL extension.

         (3)  If the IDP CRL extension is not present or omits
              onlySomeReasons but the DP includes reasons, then set
              interim_reasons_mask to the value of DP reasons.

It seems that these statements are contradict. If DP omits reasons, then the CRL segment MUST include revocation information for all reasons. But why here mention IDP include onlySomeReasons? In which scenario will this happen? Or is it just for making the algorithm can handle CRLs from non-conforming CAs?
If DP omits reasons, and IDP includes onlySomeReasons, then the iterim_reasons_mask may only include some reasons. Then RP should check another DP. Does this means in this scenario, each different DP in CDP are just released for some reasons that encoded in IDP? If DP here should be treat as all reasons, then why check another DP?

3.  in 5.2.5 Issuing Distribution Point:
   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.

  Here what is the exact meaning for scope? Does it only mean partition by onlyContainsUserCerts, or onlyContainsCACerts? And not partition by onlySomeReasons?

-Kurt Zhu

>From: Tom Gindin [mailto:[email-masked]] 
>Sent: Wednesday, May 11, 2011 8:11 AM
>To: Zhuxian
>Cc: [email-masked]
>        You can use the Distribution Point as a partition 
>identifier, and label the certificates belonging to a given 
>partition by putting that value into CRLDistributionPoints 
>while labelling the CRL using IssuingDistributionPoint.  A 
>simple scheme, which many CA implementors would use, is to 
>assign a base partition name to each partition, putting an 
>HTTP URL of the form http://(host)/(CRLDir)/(partname).crl 
>into CRLDP, and use the value (partname) as the CN attribute 
>of any directory names in an LDAP or directory name 
>DistributionPoint in CRLDP.
>DistributionPoints interoperate far better beyond a single 
>organization than directory name ones do, although not usually 
>as well as HTTP ones.
>
>                Tom Gindin
>P.S. - The opinions above are mine, and not necessarily those 
>of my employer.
>
>
>
>

---

From: Tom Gindin <[email-masked]>
Date: Wed, 11 May 2011 08:52:31 -0400

I sometimes think of the IDP extension as set up in the following 
way:
        IDP ::= GROUP { -- Just so you don't try to compile this
                distributionPoint,       -- a partition name set by the CA
                onlyTheseCertTypes BIT STRING OPTIONAL,
                onlyTheseReasons ReasonFlags OPTIONAL,
                indirect                BOOLEAN
}
        The two "ONLY" fields are similar, and if either is not present 
that one doesn't restrict the set of revocations in the CRL.  To answer 
your first question, partitioning can mean "use ONLY", "use DP", or both.
        To answer your second question, there's no contradiction.  This is 
just an example of being strict in what you create but permissive in what 
you accept.  A CA shouldn't create an IDP/CDP mismatch like that, but the 
relying party's software should use the narrower scope if they do.
        To answer your third question, the scope of a CRL with no 
Distribution Point is "all revocations other than those which don't meet 
filters which are present in the IDP extension (if any)".  If reasonFlags 
is present, all revocations for reasons other than those in that bit 
string are excluded from the scope; while if any of the "only" booleans 
for certificate type are set to TRUE, revocations of certificates of other 
types are excluded from the scope.

Tom Gindin

From:   Zhuxian <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS
Cc:     "[email-masked]" <[email-masked]>
Date:   05/11/2011 01:09 AM
Subject:        RE: [pkix] question about CRL's scope

Now I am clear why partition CRL by reason code is not RECOMMEND by this 
profile. 

However, as it is just not RECOMMEND, 5280 still support reason code based 
partition in the CRL processing algorithm.

To develop a RP supporting 5280 compliant PKI, it should also implement 
the reason code logic.

1. If conforming CAs implement partion CRL, does it mean it MUST include 
CDP and use the DP to point to the CRL segment?
     Otherwise, only out-of-band mechnism can be used to get the 
corresponding CRL segment and the security issue (such as to check the CRL 
is really the segment matched the certificate) should also be handled 
out-of-band.

It seems that these statements are contradict. If DP omits reasons, then 
the CRL segment MUST include revocation information for all reasons. But 
why here mention IDP include onlySomeReasons? In which scenario will this 
happen? Or is it just for making the algorithm can handle CRLs from 
non-conforming CAs?
If DP omits reasons, and IDP includes onlySomeReasons, then the 
iterim_reasons_mask may only include some reasons. Then RP should check 
another DP. Does this means in this scenario, each different DP in CDP are 
just released for some reasons that encoded in IDP? If DP here should be 
treat as all reasons, then why check another DP?

  Here what is the exact meaning for scope? Does it only mean partition by 
onlyContainsUserCerts, or onlyContainsCACerts? And not partition by 
onlySomeReasons?

-Kurt Zhu

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 May 2011 14:21:50 +0100

On Wednesday 11 May 2011 13:52:31 Tom Gindin wrote:
<snip>
> filters which are present in the IDP extension (if any)".

This question came up over at mozilla.dev.security.policy recently and there 
was some disagreement.

The 1997 version of X.509 says the following about the IDP extension:
"The distributionPoint component contains the name of the distribution point 
in one or more name forms. If this field is absent, the CRL shall contain 
entries for all revoked unexpired certificates issued by the CRL issuer".

However, RFC5280 doesn't seem to contain any similar text that would mandate 
any particular scope when the IDP extension is omitted.

Somebody argued that because of this, and because RFC5280 mentions the "all 
certificates issued to the NIST employees located in Boulder" scope example, 
and because X.509 is only referenced informatively (and not normatively), then 
there's nothing to stop an RFC5280-compliant CA from partitioning CRLs using 
arbitrary scopes and always omitting the IDP extension.

Time for a defect report for RFC5280?

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 11 May 2011 09:52:46 -0400

Page 65 of 5280 states:

"  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."

Clearly if IDP is absent, the DP is absent and scope of the CRL is complete  (w.r.t. to the base (vice delta))

That said, I do not object to adding more clarity to 5280.  Partitioning CRL and not assertion IDP causes security hole since relying parties cannot scope that CRL and will correctly use it and end up using a potential revoked certificate.

A more comprehensive description of CRL processing is in Annex B of X.509, which is normative for X.509, albeit may not be for 5280.  But, those rules should be treated as invariant since they are security critical.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob Stradling
Sent: Wednesday, May 11, 2011 9:22 AM
To: [email-masked]
Subject: Re: [pkix] question about CRL's scope

<snip>

Rob Stradling

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 May 2011 15:11:31 +0100

>    issuer, if any, within the scope of the CRL."

Yes, but where is the "scope of the CRL" defined?
Without a definition, the suggestion is that the CA is free to make up their 
own arbitrary scope.

The similar clause in X.509 1997 doesn't have the ", within the scope of the 
CRL" get out clause.

> That said, I do not object to adding more clarity to 5280.  Partitioning
> CRL and not assertion IDP causes security hole since relying parties
> cannot scope that CRL and will correctly

I presume you meant "incorrectly".

> use it and end up using a potential revoked certificate.
> 
> A more comprehensive description of CRL processing is in Annex B of X.509,
> which is normative for X.509, albeit may not be for 5280.  But, those
> rules should be treated as invariant since they are security critical.

<snip>

Rob Stradling

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 11 May 2011 10:16:27 -0400

Yes -- incorrectly.

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 10:12 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: [pkix] question about CRL's scope

<snip>

Rob Stradling

---

From: Zhuxian <[email-masked]>
Date: Thu, 12 May 2011 04:03:12 +0000

So totally: 

For the first question, if conforming CAs implement partition CRL, it MUST include CRL Distribution Points and use the DP to point to the CRL segment. 

For the 2nd question, some CA may issue certificate with CRL Distribution Points which includes several DP and each DP omiting the reasons field. And the CA issues several partition CRLs with IDP and  includes onlySomeReasons. 
     Then this algorithm can handle this secanrio.

For the 3nd question, partitioning CRL,  but not assertion IDP or "assertioin IDP but without distributionPoint field" causes security hole.  

am I right?

-Kurt Zhu 

>Sent: Wednesday, May 11, 2011 8:53 PM
>To: Zhuxian
>Cc: [email-masked]
>        The two "ONLY" fields are similar, and if either is 
>not present that one doesn't restrict the set of revocations 
>in the CRL.  To answer your first question, partitioning can 
>mean "use ONLY", "use DP", or both.
>        To answer your second question, there's no 
>contradiction.  This is just an example of being strict in 
>what you create but permissive in what you accept.  A CA 
>shouldn't create an IDP/CDP mismatch like that, but the 
>        To answer your third question, the scope of a CRL with 
>no Distribution Point is "all revocations other than those 
>which don't meet filters which are present in the IDP 
>extension (if any)".  If reasonFlags is present, all 
>revocations for reasons other than those in that bit string 
>are excluded from the scope; while if any of the "only" 
>booleans for certificate type are set to TRUE, revocations of 
>certificates of other types are excluded from the scope.
>
>Tom Gindin
>
>
>
>
>
>However, as it is just not RECOMMEND, 5280 still support 
>reason code based partition in the CRL processing algorithm.
>
>1. If conforming CAs implement partion CRL, does it mean it 
>MUST include CDP and use the DP to point to the CRL segment?
>     Otherwise, only out-of-band mechnism can be used to get 
>the corresponding CRL segment and the security issue (such as 
>to check the CRL is really the segment matched the 
>certificate) should also be handled out-of-band.
>
>It seems that these statements are contradict. If DP omits 
>reasons, then the CRL segment MUST include revocation 
>information for all reasons. But why here mention IDP include 
>onlySomeReasons? In which scenario will this happen? Or is it 
>just for making the algorithm can handle CRLs from non-conforming CAs?
>If DP omits reasons, and IDP includes onlySomeReasons, then 
>the iterim_reasons_mask may only include some reasons. Then RP 
>should check another DP. Does this means in this scenario, 
>each different DP in CDP are just released for some reasons 
>that encoded in IDP? If DP here should be treat as all 
>reasons, then why check another DP?
>
>  Here what is the exact meaning for scope? Does it only mean 
>partition by onlyContainsUserCerts, or onlyContainsCACerts? 
>And not partition by onlySomeReasons?
>
>-Kurt Zhu
> 
>
>>        You can use the Distribution Point as a partition identifier, 
>>and label the certificates belonging to a given partition by putting 
>>that value into CRLDistributionPoints while labelling the CRL using 
>>would use, is to assign a base partition name to each partition, 
>>putting an HTTP URL of the form http://(host)/(CRLDir)/(partname).crl
>>into CRLDP, and use the value (partname) as the CN attribute of any 
>>directory names in an LDAP or directory name DistributionPoint in 
>>CRLDP.
>organization