[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CRL Distribution Points
I interpret RFC 2459, Section 5 to mean that the relying parties may
encounter ARL, DP CRL, and delta CRL. Given that, the entire text of Annex
is pertinent to 2459, not just the check for indirect CRL issuer. This can
be done either by reference or by inclusion.
-----Original Message-----
From: Peter Williams [mailto:peterw@valicert.com]
Sent: Wednesday, October 27, 1999 3:23 PM
To: Santosh Chokhani; 'Russ Housley'; ietf-pkix@imc.org
Subject: RE: CRL Distribution Points
ftp://ftp.bull.com/pub/OSIdirectory/documentsForBallot/CertExtFPDAM.doc
At your suggestion I have reviewed the above-identified
amendment text.
For those who only want the bottom line of this mail, here it is:
I suggest that a simple statement is added to that which
Russ has already drafted: it should state that
"X.509 processing of the crlIssuer field is REQUIRED, if
present".
Annex M review, for the purpose or understanding Russ' request
for comment in light of Annex M:
I note, that wherever CA was formally, used,
the more general term "authority" is now substituted.
Authority is defined as CA or AA.
I note that the concepts of CrlDistribution Point
have not changed by amendment from the
X.509 version used by 2459.
I do note that the whole concept of DPs has
been extended to the PMI, which is not part
of 2459 work. I ignored everything in 13.14
as out of review scope, for now.
Annex M1.1 states the CRL types, and helps
out the new scope idea, which is not part
of this review.
Annex M.2 specifies a logical procedure for
selecting CRL processing, based on CRL reliance
policy, defined in the CP.
Annex M.3 states the rules for selecting a CRL
from the various flavors available, according to
various requirements. The annex makes it
clear that 1 or more of the several DPs provided can
be used when DP processing is appropriate.
The concept of dominance and freshness, nicely allows
the IBM override of VeriSign that I described,
whether or not cRLIssuer processing is used.
M.5.1.4 addresses one interaction of cert-based DP
signals and CRL-hosted DP signals.
The first bullet points out a alternative matching rule
covering DPName, or the optional CrlIssuer name. Either match is acceptable.
The last bullet states the crlIssuer rule I stated originally.
Annex M is very nice piece of work, which makes it easier
to do what the market requires.
Annex M is completely consistent with my argument, and
does not change the way X.509 has handled cRLIssuer
and indirect CRL signals.
Russ should ensure that his overloading of semantics
on the cRLissuer field continue require that the
base X.509 rules are followed, as stated in X.509
and even more forcefully stated in Annex M.5.1.4
of the FPDAM.
Is that a fair review and conclusion, tuned to the question
posed?
The review only reinforced my original conclusion. Let
me know if I have made an error in my reasoning, or
if there are other factors in play. I just do
not want PKIX to be non-conforming with X.509.
I suggest that a simple statement is added to that which
Russ has already drafted: it should state that
"X.509 processing of the crlIssuer field is REQUIRED, if
present".
Thanks for insisting we all review Annex M. Persistence
in leadership does pay dividends.
Peter.
that indirect issuance is the same as used in the
> -----Original Message-----
> From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
> Sent: Wednesday, October 27, 1999 11:18 AM
> To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> ietf-pkix@imc.org
> Subject: RE: CRL Distribution Points
>
>
> Peter:
>
> You really need to carefully review the Annex M in the draft.
> That should
> explain it all. If you find incompleteness, errors or
> inconsistencies in
> that Annex, please let me know. We would be interested in
> making that Annex
> as complete and accurate as possible.
>
>
> -----Original Message-----
> From: Peter Williams [mailto:peterw@valicert.com]
> Sent: Wednesday, October 27, 1999 2:16 PM
> To: Santosh Chokhani; 'Russ Housley'; ietf-pkix@imc.org
> Subject: RE: CRL Distribution Points
>
>
>
>
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
> > Sent: Wednesday, October 27, 1999 8:16 AM
> > To: 'Peter Williams'; Santosh Chokhani; 'Russ Housley';
> > ietf-pkix@imc.org
> > Subject: RE: CRL Distribution Points
> >
> >
> > Peter:
> >
> > My interpretation of the statement is that the issuer name in the
> > certificate should match the issuer name in the CRL.
>
> This interpretation interferes with the X.509 specification which
> enables use of ANY independently-named (validation) authority. The
> CrIssuer field signals the identity and intended use of a given
> authority to relying parties, when optionally present. If the
> cRLIssuer value is not present, the default rule you mention
> above controls. Otherwise "the issuer name in the
> **cRLIssuer** value should match the issuer name in the CRL."
>
> Let us also note that the name of the CRLDP, when the
> RDN flavour is used, is subordinate to the **CRL issuer**,
> as identififed using the CrlIssuer Rule, if one
> is performing conforming processing. The cRLIssuer
> is identified using the processing summarized above.
>
> Why cannot we do the simple thing, and just implement
> what X.509 specifies? Its hardly contentious, its
> not hard, and has already been ratified by the ISO voting
> process, which included a PKIX voice.
>
> Lets now advocate the case, with famous-name examples to
> make the case easier to follow:
>
> Case
> ----
>
> Folk have quite widely adopted the separation of power idea
> between CAs and VAs (or those who indirectly
> issug CRLs). Enterprises WANT to be able to
> issue a local/extranet CRL, that controls whether a VeriSign
> public certificate is flagged suspended in that
> relying-party domain.
>
> Taking IBM as the example enterprise customer that chooses
> to quite normally outsource its ceritifcate manufacturing to
> VeriSign, IBM may well wish to have VeriSign indicate
> the users of IBM certificates should use a given , non-VeriSign
> CRL issuer, identified in the CrlIssuer name using
> an DN selected in the IBM corporate DN-name space.
>
> Policies for issuing IBM's indirect CRL would meet IBM
> guidelines, which may be more stringent than the those used by
> VeriSign. Furthermore, for IBM is likely to have
> a significantly more realtime data at its RAs concerning
> revocation/suspension data than VeriSign has, or has yet
> accepted for processing under its own CPS rules.
>
> Whether IBM or an outsource VA operate the IBM
> CrlIssuer is an operational choice, much like
> any decision to deploy a product server on
> the IBM LAN, or use a service provider.
>
>
> Conclusion, to date:
> -------------------
>
> The model argued above is what the cRLIssuer field
> was designed for; processing must comply for a
> user cert validation result to be conforming with X.509,
> and for the allied process of confirming a certificate chain
> to be similarly conforming.
>
> I have no particular objection, if it is
> technically appropriate, for PKIX to overload the CrlIssuer
> signal with Russ' meanings
>
> But one cannot simple replace
> the original processing requirements with an
> interpretative wave of the PKIX magic wand, and
> still be able to interwork securely with
> correctly-implemented X.509 certificate-using
> systems now widespread.
>
> Peter.
>
> >
> > -----Original Message-----
> > From: Peter Williams [mailto:peterw@valicert.com]
> > Sent: Tuesday, October 26, 1999 8:35 PM
> > To: Santosh Chokhani; Peter Williams; 'Russ Housley';
> > ietf-pkix@imc.org
> > Subject: RE: CRL Distribution Points
> >
> >
> >
> >
> > > 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) }
> > > >
> > >
> >
>