[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Usage of CRL Issuing Distribution Point
When a CA publishes a CRL, the CA should put sufficient information into the
CRL to unambiguous identify its intent. If you CA is only generating one CDP
per signing key, then issuer and key identity is sufficient. The key
identity in AKI is just a hint to enable you to pick the right CRL first for
you signature check. It also helps if you want to cache CRL locally. Issuing
CDP is required once a CA starts to partition the CRL based e.g. on reason
code or subject type. The current RFC does not permit CRL to be partitioned
on the basis other attributes such as serial number. The Issuing CDP of a
CRL tells you by a piece of signed data, that out of all the CRL that are
published by the CA and current what exactly was the intent of the CA when
it created this CRL. Trusting where you find the CRL to give you this
information is not good practice. Distribution mechanisms such as
directories and url's cannot be trusted.
-----Original Message-----
From: Ambarish Malpani [mailto:ambarish@valicert.com]
Sent: Wednesday, February 10, 1999 12:11 PM
To: pau@watson.ibm.com; ietf-pkix@imc.org
Cc: carlisle.adams@entrust.com
Subject: RE: Usage of CRL Issuing Distribution Point
Hi Pau,
If your CA is "really" using CRLDP, then you need to be
careful when you say you have "the" CRL. Part of the point of
CRLDP (as opposed to simple CRLs), is, that a CA can now issue
multiple little CRLs, depending on how it decides to partition
revocation data.
For example, it may create one CRLDP for certificates with serial
numbers between 1-100. Another one for certs from 101-200 and so
on.
Also, it may decide to issue multple potential CRLs on which
a particular cert may occur - for example, there may be one CRL
for key compromise (which is updated very, very frequently), another
for lost keys, etc.
So, there isn't necessarily a single CRL you need to look at.
If your CA decides to use CRLDP in its simplest form and just
issue a single CRL that contains all revocation data, you
still need to be careful. A CRL contains 2 times - a thisUpdate
and a nextUpdate, where the thisUpdate is the time at which
the CRL was issued, while the nextUpdate is the time
at or *before* which the next CRL will be issued.
This means that there is *no* guarantee that the CRL you have
from the CA is the latest one it issued. So depending on the
sensitivity of the transaction, you may decide to go check
the CA for a newer CRL, use the cached CRL, or wait till
nextUpdate is in the past, go grab a new CRL from the CA at
that time and verify that the cert is not on that CRL.
Hope this helps,
Regards,
Ambarish
P.S. To figure out which CRLs apply to the certificate you are
trying to check, you normally look for the path to the CRLs in
the certificate. Once you retrieve the CRL, you need to check
that the CRL has the same name as the one you thought you
were retrieving. So the extension you look for in the cert
is the one with OID id-ce-cRLDistributionPoints, while the name
of the CRL can be found in the CRL (if present), with the
OID id-ce-issuingDistributionPoint.
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
1215 Terra Bella Ave. http://www.valicert.com
Mountain View, CA 94043-1833
> -----Original Message-----
> From: owner-ietf-pkix@imc.org
> [mailto:owner-ietf-pkix@imc.org]On Behalf
> Of pau@watson.ibm.com
> Sent: Monday, February 08, 1999 8:55 AM
> To: ietf-pkix@imc.org
> Subject: Usage of CRL Issuing Distribution Point
>
>
> Hellow, I am a new comer to PKIX.
> I have a question about the usage of the
> CRL distribution point:
>
> If I have the CRL, then do I still need to know
> the distribution point ? Is this entension intended
> for furture retrival of CRL's (and of course, to indicate
> why the cert's in the list are revoked.) ?
>
> If I don't know the distribution point, is there a
> standard/suggested way to learn it without getting the
> CRL ?
>
> Thanks in advance.
>
>
> Regards, Pau-Chen
>