[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Usage of CRL Issuing Distribution Point



What extensions in these documents provide for other attributes to be used
to partition CRLs? 
-----Original Message-----
From: Alex Deacon [mailto:alex@verisign.com]
Sent: Friday, February 12, 1999 12:40 PM
To: Trevor Freeman
Cc: 'ietf-pkix@imc.org'
Subject: RE: Usage of CRL Issuing Distribution Point


Trevor, 

Could you specify what document states that it is not permitted for CRL's to
be partitioned on the basis of other attributes such as serial number?  I
cant recall ever seeing such a statement in either PKIX Part 1 or X.509.

Thanks
Alex

> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@microsoft.com]
> Sent: Friday, February 12, 1999 11:07 AM
> To: 'Ambarish Malpani'; pau@watson.ibm.com
> Cc: ietf-pkix@imc.org
> Subject: 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
> > 
>