12

Here's an example PKI setup:

* Root CA (offline)
  * Issuing CA
    * Client 1
    * Client 2

I'd like to specify a CRL distribution point for CRLs generated by Root CA, and an OCSP URL for Issuing CA. So information about revoked client certificates is available only via OCSP. Information about a revoked Issuing CA (hopefully never needed) is available only via CRL.

The question is which one of these two ways is the correct way to communicate this policy:

* Root CA (CRL distribution point = http://...)
  * Issuing CA (OCSP = http://...)
    * Client 1
    * Client 2

or

* Root CA
  * Issuing CA (CRL distribution point = http://...)
    * Client 1 (OCSP = http://...)
    * Client 2 (OCSP = http://...)

Basically, I'm confused about who specifies URIs for obtaining revocation information. Is this specified in the CA's certificate, meaning "I'm the CA, and this is where I'll tell you about certificates I've issued that are no longer valid," or is this specified in the client certificate, meaning "if this certificate gets revoked, here's where you'll find out about it?"

I've looked through RFC 5280 and couldn't find a clear answer to this question. Most examples suggest that the second way is correct, but the first one seems to make more sense to me. Which one is it?

If the second way is correct, is there any reason to also specify CRL distribution points in the Root CA?

Improve this question

2 Answers 2

Reset to default
10

Short version: all the URI should be in the end-entity certificates.

For OCSP, the location of the OCSP responder should be specified in an Authority Information Access extension, which is described in section 4.2.2.1 of RFC 5280:

The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears.

The OCSP responder able to give revocation information on a given EE certificate is part of a service of the CA, i.e. the issuer of the EE certificate. So the URI should be published as an extension of the EE certificate, as per the sentence quoted above.

For CRL, the primary role of the CRL Distribution Points extension is to segregate certificates into subsets, so that individual CRL may have a limited scope and remain short. This mechanism works by having the same "distribution point" appear in both the EE certificate (as part of a CRL Distribution Points extension) and the CRL which applies on that certificate (as part of an Issuing Distribution Point extension) (see section 4.2.1.13). Since distribution points contain "names" and names can be URI, it is customary to use such an URI as pointing to the place from where the CRL may be downloaded.

That OCSP responder and CRL download URI appear in the target certificate (the one whose revocation status is to be ascertained) makes sense: the corresponding servers are under the control of the issuing CA, so the URI are chosen by that CA, and can be set only in certificates whose contents are under control of the CA. The CA does not get to arbitrarily choose the contents of its own certificate: that certificate is issued by an upper CA (here, the "root CA"). Hence, the CA stuffs its URI into the certificate that it issues itself (the end-entity certificates).

Improve this answer
2
  • I've done a bit more reading over the past 24 hours and your explanation is consistent with the other information I found. I also didn't know about the Issuing Distribution Point extension, so thanks for pointing that out. The only remaining question is about including CDP in the Root CA certificate. Some people recommend against it, but a number of certificates installed in web browsers (Firefox & IE) do contain CRL download info. Your thoughts?
    – VokinLoksar
    Commented Dec 28, 2011 at 15:42
  • @VokinLoksar: root CA "certificates" are a Tradition. Nominally, path validation begins with a "Trust Anchor" which is a name, a public key, and some initial conditions for the algorithm. There is widespread usage of locally storing such information under the guise of an X.509 certificate, often self-signed (because there is a field for a "signature" -- that signature buys nothing for security, and nobody ever verifies it). Yet this is traditional, not standard, and interpretation of whatever extensions may be in that certificate is totally up to the application. Most will ignore them.
    – Thomas Pornin
    Commented Dec 28, 2011 at 16:28
1

This is a good question cause specification is vague on this.

Our validation code assumes that end-entity certificate contains OCSP and CRL addresses, used to validate this certificate. I.e. we assume something like

  • Root CA
    • Issuing CA
      • Client 1 (CRL distribution point = http://..., OCSP = http://...)
      • Client 2 (OCSP = http://...)
      • Client 3 (CRL distribution point = http://...)
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .