[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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) }
> > >
> >
>