Subject: RE: Usage of CRL Issuing Distribution Point - msg#00106

Previous Message by Date: click to view message preview

Re: Yes, and remove more of the alphabet from the PKIX soup

Al and Bill: Thanks, the chronology helps put things in perspective. It sounds as though some view CMC as the next phase certificate management protocol which will address deficiencies in CMP and CRS. I hope that means future CMP work is limited to incremental fixes and improvements rather than competing with CMC enhancements. Is this the case? Still, if anyone experienced with both can summarize the deficiencies that CMC is trying to address, it would be appreciated. Thanks in advance: Eric Bomarsi "Flanigan, Bill" wrote: > Hello Al/Eric, > > IMHO, CMC (needs a much-broader, descriptive name?) appears to be the > "logical successor" to CMP as well as the rest of the PKIX alphabet soup of > somewhat contradictory I-Ds/RFCs. CMP now seems too narrowly focused and > not fully formed. This is to be expected, since CMP drew on the experience > of only a small number of smart folks who had hands-on, post-pilot, > PKI-implementation experience (they were probably the only ones on the > planet at the time!). CMC (or an updated, unified spec) offers the > opportunity for many more folks who now have had hands-on experience with > major PKI implementations (especially with the registration process and > directories) to contribute to a more mature, deconflicted, and homogeneous > protocol that can be implemented by many "flavors" of PKI using out-of-the > box components without glueware. > > Bill > > -----Original Message----- > From: Al Arsenault [ mailto:aarsenault@xxxxxxxxxx > <mailto:aarsenault@xxxxxxxxxx> ] > Sent: Thursday, February 11, 1999 1:21 PM > To: Eric Bomarsi; ietf-pkix@xxxxxxx <mailto:ietf-pkix@xxxxxxx> > Subject: RE: Yes, and remove more of the alphabet from the PKIX soup > > Eric, > > At 12:23 PM 2/11/99 -0500, Eric Bomarsi wrote: > >I am trying to understand the relationship between the various > >certificate enrollment protocols and came across this archived > >email thread. <snipped> > > > >Since then, CMP is going to RFC, CMMF seems to be > >going away, and CMC work continues. Correct? > > > > Correct. > > >So can someone with experience in each of these please > >summarize the merits of each? > > > >Is CMC a follow-on to CMP and intended to improve some > >deficiencies, or are they competing protocols. > > [snip] > > Yes, the two protocols (CMP and CMC) are "competing" with one > another. CMP was created first (it evolved out of the original PKIX-3 > document); then CMC (which was originally CRS) was proposed as an > alternative by a group of people who didn't want to deal with the creation > of a new protocol. Vendors generally choose one or the other to implement; > certain vendors (I'll let them speak for themselves) have said publically > that they're going to support CMC and never implement CMP; other vendors > have made similar commitments to CMP and seem to shun CMC. I'm not aware of > anybody who has made a public commitment to support both, but there might be > somebody. > > [snip] Al > Arsenault > > [snip] .

Next Message by Date: click to view message preview

[Q] AuthorityKeyIdentifier Question

Hi all, I have a question about matching authorityCertIssuer in AuthorityKeyIdentifier extension with authority certificate. I understand authorityCertIssuer has to match issuer (and/or?) issuerAltName of the issuer certificate. Since authorityCertIssuer is GeneralNames and issuer is a Name (distinguished name), in what manner one should be matched against the other? Alternatively, if authorityCertIssuer is supposed to be matched only with issuerAltName, which is GeneralNames, doesn't it mean that presence of authorityCertIssuer in the subject's certificate requires the presence of issuerAltName in the issuer's certificate and the presence of subjectAltName in the issuer issuer's certificate. The clarification will be really appreciated. --Dmitry

Previous Message by Thread: click to view message preview

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@xxxxxxxxxxxx 1215 Terra Bella Ave. http://www.valicert.com Mountain View, CA 94043-1833 > -----Original Message----- > From: owner-ietf-pkix@xxxxxxx > [mailto:owner-ietf-pkix@xxxxxxx]On Behalf > Of pau@xxxxxxxxxxxxxx > Sent: Monday, February 08, 1999 8:55 AM > To: ietf-pkix@xxxxxxx > 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 >

Next Message by Thread: click to view message preview

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@xxxxxxxxxxxxx] > Sent: Friday, February 12, 1999 11:07 AM > To: 'Ambarish Malpani'; pau@xxxxxxxxxxxxxx > Cc: ietf-pkix@xxxxxxx > 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@xxxxxxxxxxxx] > Sent: Wednesday, February 10, 1999 12:11 PM > To: pau@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx > Cc: carlisle.adams@xxxxxxxxxxx > 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@xxxxxxxxxxxx > 1215 Terra Bella Ave. http://www.valicert.com > Mountain View, CA 94043-1833 > > > > -----Original Message----- > > From: owner-ietf-pkix@xxxxxxx > > [mailto:owner-ietf-pkix@xxxxxxx]On Behalf > > Of pau@xxxxxxxxxxxxxx > > Sent: Monday, February 08, 1999 8:55 AM > > To: ietf-pkix@xxxxxxx > > 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 > > >