RE: CRL Distribution Points

[Peter Williams <peterw@xxxxxxxxxxxx>]

> Peter:
> 
> The issuer of the CRL should be identified from issuer name 
> field in the CRL
> and not based on what directory entry or what attribute you 
> queried.  The
> directory is not trusted, the network is not trusted, and 
> there is no strong
> binding between the attribute value and the object/attribute.

But, from the standard(12.6.2	Certificate extension fields)
at ftp://ftp.bull.com/pub/OSIdirectory/ITU/97x509final.doc

"The cRLIssuer component identifies the authority that issues and signs the
CRL. If this component is absent, the CRL issuer name defaults to the
certificate issuer name."

I assume we are going to comply with X.509 concerning
the rules for identifying the issuer of a CRL, as given
above.  If not, the security section of son-of-2459 should
identify that PKIX validation processing is non-conforming with
the ISO standard.  
 
Peter.


> -----Original Message-----
> From: Peter Williams [mailto:peterw@valicert.com]
> Sent: Tuesday, October 26, 1999 8:02 PM
> To: Santosh Chokhani; 'Russ Housley'; ietf-pkix@imc.org
> Subject: RE: CRL Distribution Points
> 
> 
> Russ,
> 
> You need to ensure that an indirect issuer of the
> CRL fragment can be identified, so that the signature
> can be appropriately verified, as per the X.509 model.
> 
> How would we do that with your standard today? - whilst
> also pointing to the location of the value in 
> a directory/uri-resolver?
>  
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
> > Sent: Tuesday, October 26, 1999 4:39 PM
> > To: 'Russ Housley'; ietf-pkix@imc.org
> > Subject: RE: CRL Distribution Points
> > 
> > 
> > Russ:
> > 
> > Please Annex M on X.509 Draft Amendment.  It will be a good 
> > idea to include
> > Annex M, point to it or borrow the applicable sections in the 
> > PKIX RFC.
> > 
> > -----Original Message-----
> > From: Russ Housley [mailto:housley@spyrus.com]
> > Sent: Tuesday, October 26, 1999 12:58 PM
> > To: ietf-pkix@imc.org
> > Subject: CRL Distribution Points
> > 
> > 
> > In reviewing the document that Tim recently posted, I 
> > realized that we were 
> > not really clear about the semantics of a DistributionPoint 
> > with an absent 
> > distributionPoint, a present reasons, and a present 
> > cRLIssuer.  The ASN.1 
> > is repeated below for those who have not memorized it.
> > 
> > If the cRLDistributionPoints extension does not contain a 
> > DistributionPointName, but does contain a cRLIssuer, then following 
> > semantics MUST be assumed:
> > 
> > 1) If the cRLIssuer is of type directoryName, then the 
> > certificateRevocationList attribute in the Directory entry of 
> > the cRLIssuer 
> > contains the current CRL for the associated reasons.
> > 
> > 2) If the cRLIssuer is of type URI, then the URI is a 
> pointer to the 
> > current CRL for the associated reasons.  The expected values 
> > for the URI 
> > are those defined in 4.2.1.7.
> > 
> > 3) Processing rules for other values are not defined by this 
> > specification.
> > 
> > Does this seem right?
> > 
> > Russ
> > 
> > = = = = = = = = = =
> > 
> >     CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF 
> > DistributionPoint
> > 
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     
> > DistributionPointName OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> > 
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> > 
> >     ReasonFlags ::= BIT STRING {
> >          unused                  (0),
> >          keyCompromise           (1),
> >          cACompromise            (2),
> >          affiliationChanged      (3),
> >          superseded              (4),
> >          cessationOfOperation    (5),
> >          certificateHold         (6) }
> > 
>