Subject: RFC5280 : Applications and CRL DP extension support

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 15 Jul 2009 16:02:53 +0200

The text of RFC5280 says :
4.2.1.14 CRL Distribution Points
     [...] this profile
     recommends support for this extension by CAs and applications.

Whilst I 100% approve the recommendation for CAs (No CA should issue 
certificates without CRLDP when they do provide CRL), what does it in 
practice mean for applications ?

They are cases where dynamically  downloading the CRL by interpreting 
the CRL DP extension is inappropriate for some applications, and where 
the needs and context of the application make it much more adequate to 
instead to configure in advance the location where the CRL of the 
supported CAs can be found.

Some examples  :
- Closed networks : Network access to the open internet and the CRL DP 
might be simply unavailable, and the application should get CRLs from 
copies made at alternative locations on the local network.
- Controled network : Even if no alternative local location is provided, 
network rules may forbid network  access that has not been vetted 
beforehand, so make it inappropriate if the application tries to 
download data from a location based on the information contained in any 
the certificate it just received
- Performance : When the application has to validate a hich volume of 
certificates, dynamic loading of the CRL is simply inappropriate. This 
can be worked around by using caching mechanisms, but it will be more 
adequate to use configuration particularly if the application already 
configures rules about how often to download new CRLs (CRLS quite often 
are renewed more frequently than their nextUpdate field signals, some CA 
renew their CRL every day, but have a nextUpdate filed valid for one week).

So whilst it's very useful to have the CA include the information inside 
the certificate, I think the standard should not try to constrain the 
methods by which the application will get it's up to date revocation 
info, or make it clearer that the use of alternates is appropriate when 
they will give the same result.

Can I have confirmation from the group that the text in RFC5280 is *not* 
intended to discourage applications under such circumstances from using 
configuration settings instead of dynamically reading the CRL DP 
extension content  ?

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 15 Jul 2009 17:51:14 +0200

>     recommends support for this extension by CAs and applications.
the full text is:

 The CRL distribution points extension identifies how CRL information
   is obtained.  The extension SHOULD be non-critical, but this profile
   RECOMMENDS support for this extension by CAs and applications.

> certificates without CRLDP when they do provide CRL),
It is a recommandation, but not a requirement. Why do you approve the 
recommandation?

> what does it in practice mean for applications ?
>
>
it depends what you mean by "dynamically". If you say: immediately, 
instantaneously, or during path
validation, then I agree with you. a relying party should  not be 
required to have a working
network connection to an uncontrollable environment.

The first sentence coul  probably be enhanced to read:
 "can be obtained", or "where the CA publishes a CRL for this cert"
> - Controled network : Even if no alternative local location is 
> provided, network rules may forbid network  access that has not been 
> vetted beforehand, so make it inappropriate if the application tries 
> to download data from a location based on the information contained in 
> any the certificate it just received
> configures rules about how often to download new CRLs (CRLS quite 
> often are renewed more frequently than their nextUpdate field signals, 
> some CA renew their CRL every day, but have a nextUpdate filed valid 
> for one week).
The CA defines in its policy the source of CRLs. It also defines what 
kind of relying parties are possible.
If the a relying party is not able to use a "correct" crldp pointer due 
the first two cases, then one of the
parties hasn't done its job. resolving the url may also lead to 
different physical servers

performance: a local OCSP validation server (one of the first kind) can 
be regarded as just such a cache.
Unfortunately, the server cannot really "learn", because it never 
actually sees a certificate.

>
>
> So whilst it's very useful to have the CA include the information 
> inside the certificate, I think the standard should not try to 
> constrain the methods by which the application will get it's up to 
> date revocation info, or make it clearer that the use of alternates is 
> appropriate when they will give the same result.
The standard doesn't constrain this IMO. A recommandation is not a MUST.

>
>
> Can I have confirmation from the group that the text in RFC5280 is 
> *not* intended to discourage applications under such circumstances 
> from using configuration settings instead of dynamically reading the 
> CRL DP extension content  ?
>
>
The standard doesn't say that you have to get the information in a 
"dynamic" way IMO. loading crls
from a file which is updated in intervals is an implementation detail 
for a relying party.
I would thus vote: 'confirmed'.

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 15 Jul 2009 11:56:16 -0400

Hi Jean,

your pledge for more dynamic approach to CRLs (but this could be applied
to any URLs embedded into certificates) is well known. Take a look at PRQP
(PKI Resource Query Protocol), currently a draft (you can download it
from the PKIX WG page): this should provide a solution to that by having
an authoritative source of information (instead of having just a
"configuration" file).

Hope this will help,

Best,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 19 Jul 2009 16:23:40 +0200

Jean,

An aspect of this often forgotten is that a major practical function of the
CRLDP is to act as an identifier used to match the certificate and the CRL.

When a CRLDP is present in a certificate and an Issuing Distribution point
extension is present in the CRL, them the distribution points of these
extensions MUST match as defined in section 5.2.5 of RFC 5280.

As far as I recall, there are no requirements that the location stated in
the CRLDP need to be used to obtain the CRL.

The URL stated in CDP may further be relative (and refer the relying party
to the resource on the local network).

/Stefan.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 19 Jul 2009 11:24:10 -0400

Stefan,

The imprecision in the statement below can lead to security problem.  If
IDP is present in a CRL with DP in the IDP, even if there is no CRL DP
in the certificate, that CRL with DP in IDP can not be used by relying
parties since whether the CRL covers the scope of the certificate or
not, is unknown.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Sunday, July 19, 2009 10:24 AM
> To: Jean-Marc Desperrier; [email-masked]
> Subject: Re: RFC5280 : Applications and CRL DP extension support
> 
> 
> Jean,
> 
> An aspect of this often forgotten is that a major practical 
> function of the CRLDP is to act as an identifier used to 
> match the certificate and the CRL.
> 
> When a CRLDP is present in a certificate and an Issuing 
> Distribution point extension is present in the CRL, them the 
> distribution points of these extensions MUST match as defined 
> in section 5.2.5 of RFC 5280.
> 
> As far as I recall, there are no requirements that the 
> location stated in the CRLDP need to be used to obtain the CRL.
> 
> The URL stated in CDP may further be relative (and refer the 
> relying party to the resource on the local network).
> 
> /Stefan.
> 
> 
> > some CA renew their CRL every day, but have a nextUpdate 
> filed valid for one week).
> >

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 01:20:16 +0200

Santosh,

Agreeing and I don't think our observations are in conflict.
You need to make sure both that you cover all relevant scopes as well as the
CRLs you are using matches the certificate you validate. I was only
addressing the latter.

/Stefan

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 20 Jul 2009 11:54:27 +0200

> extensions MUST match as defined in section 5.2.5 of RFC 5280.

Yes, of course, but if support of CRLDP is only really required in that 
meaning, then there's a mismatch between the fact that application 
support of CRLDP is recommended, but support of IDP is optional (given 
that IDP  MUST be critical):

    4.2.1.13.  CRL Distribution Points
    [...] this profile
    RECOMMENDS support for this extension by CAs and applications.

    5.2.5.  Issuing Distribution Point
    [...] conforming implementations are not required to support
    this extension

Maybe the RECOMMENDS for CRL DP should best be read as meaning that the 
application SHOULD be able to parse and make the info available to the 
user ?

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 12:17:29 +0200

Jean,

CRLDP is not required in that meaning, but matching distribution points is
an extra feature to ensure that you are actually using the right CRL.

The basic assumption for PKI is that CA names are selected in a way that
you will not trust several CAs with identical names at the same time.
Following that assumption it is sufficient to match the name of the
certificate issuer in the certificate and the CRL.

In the absence of an IDP, the CRL must have a complete scope, and most CRLs
are issued with a complete scope.

However, It was once a disjoint in the way Microsoft issued its CRLs that
they allowed CRLs to cover "only" certificates issued under one CA key
without including IDP in the CRL, even if that CA under the same name had
issued certificates with another key. They had to add an IDP to the CRLs to
allow that limited scope. In this case the matching of distribution points
helps identifying the scope of the CRL by ensuring that you are looking at
the intended CRL for the certificate you are validating.

So it is logical to me that CDP is recommended to support CRL discovery, but
allowing IDP to be optional as long as the CRL has a complete scope.

/Stefan