[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3280bis: CRL validation
I think you misunderstand my example.
The EE Cert is checked with an indirect CRL indicating CRL issuer Z as
CRL issuer. It is indirect since CRL Issuer Z <> CA Y that issued the
cert.
Based on what I understand of your model, given that IDP - CDP match,
then both indirect CRLs in my example, would match that certificate.
Stefan Santesson
Program Manager, Standards Liaison
Windows Security
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Santosh Chokhani
> Sent: den 14 juni 2005 18:34
> To: ietf-pkix@xxxxxxxx
> Subject: RE: 3280bis: CRL validation
>
>
> Stefan,
>
> There is misunderstanding of the model on your part. For direct CRL,
the
> entire path must match up to the last issuer and hence that can not
> happen.
>
> All you are doing is DN matching (one for one) in both paths ignoring
> self-issued certificate.
>
> Thus, your understanding is incorrect.
>
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, June 14, 2005 8:15 AM
> To: Santosh Chokhani; ietf-pkix@xxxxxxxx
> Subject: RE: 3280bis: CRL validation
>
>
>
> Santosh,
>
> Just to be honest, your model, as I understand it, does not handle all
> possible cases:
>
> For CRL paths:
>
> Root 1 --> CA X --> CRL issuer Z --> CRL
> Root 1 --> CA X --> CA Y --> CRL issuer Z --> CRL
>
> A certificate issued under:
>
> Root 1 --> CA X --> CA Y --> EE Cert
>
> ...Could accept both CRLs above
>
> /Stefan
>
>
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On Behalf Of Santosh Chokhani
> > Sent: den 13 juni 2005 15:46
> > To: ietf-pkix@xxxxxxxx
> > Subject: RE: 3280bis: CRL validation
> >
> >
> > Denis,
> >
> > It is not clear from this e-mail thread what the solution is, what
the
> > certificate issuer as the existing extension is (unless you mean the
> CRL
> > entry extension, which is not required or recommended and is useless
> in
> > the
> > direct CRL). It is also not clear what problem this solution is
> > addressing.
> >
> > The problem I am addressing is as follows. Let us say that there
are
> > following PKIs:
> >
> > Root 1 --> CA A --> Orion
> > Root 2 --> CA B --> CA I --> Orion
> > Root 2 --> CA C --> CA J --> Orion
> >
> > Assuming that the three Orions are distinct, I am addressing the
> problem
> > that the wrong CRL does not get fetched and used.
> >
> > If you can describe how you solve this problem, what extensions
> > certificates and CRLs have in them and what the relying parties do
> > with them, I
> will be
> > happy to determine if the solution deals with the problem and if it
is
> > less complex than what I proposed.
> >
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> > On
> > Behalf Of Denis Pinkas
> > Sent: Monday, June 13, 2005 5:14 AM
> > To: ietf-pkix@xxxxxxxx; Santosh Chokhani
> > Subject: Re: 3280bis: CRL validation
> >
> >
> >
> > Santosh,
> >
> > Since it took you less thah 15 minutes to reply, it means that you
did
> not
> > pay
> > enough attention to the content of my short message. :-)
> >
> > >Denis,
> >
> > >We may be solving different problems.
> >
> > Certainly. You try to solve a more complex problem that belongs to
the
> > case
> > b) category. Once case a) is solved, then we can talk of the
> "zillions"
> > cases b).
> >
> > > I am solving the problem of names not being unique.
> >
> > You would have to be more specific so that I can really make sure
what
> you
> > mean here.
> >
> > > There is no need or benefit to adding a new extension.
> >
> > As far as I am concerned, I am using currently defined extensions.
> >
> > >May be you are proposing to list the names of the CA's in the path
in
> > >this extension.
> >
> > This was my proposal to solve the "zillions cases", but not to solve
> case
> > a).
> >
> > > If so, the solution does not fit today's extensions and lacks
> agility
> > >of the algorithm I proposed and has the same or greater complexity.
> >
> > For case a), one single name is necessary. That name cannot be
> ambiguous
> > since it can only be given by the CA that has issued the target
> > certificate.
> >
> >
> > My point is the following:
> >
> > "For case a), the name(s) contained in certificateIssuer MUST be
> certified
> > by the CA that has issued the certificate where the extension
> appears".
> >
> > Denis
> >
> > >It will not reduce the complexity since the same matching will be
> > >requiring.
> > >
> > >You saying that you do not understand my posting is akin to turning
a
> > >deaf ear to a discussion.
> > >
> > >-----Original Message-----
> > >From: owner-ietf-pkix@xxxxxxxxxxxx
> > >[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
> > >Sent: Friday, June 10, 2005 12:55 PM
> > >To: ietf-pkix@xxxxxxxx; Santosh Chokhani
> > >Subject: Re: RE: 3280bis: CRL validation
> > >
> > >
> > >
> > > >Denis,
> > >
> > >>What is your solution?
> > >
> > >There are two cases to consider for CRL issuers.
> > >
> > > a) the CRL Issuer issues revocation information for a single CA;
> > > b) the CRL Issuer issues revocation information for more than one
> CA.
> > >
> > >Case a) is simple, while case b) is more much complex (this is the
> > >"zillions of cases").
> > >
> > >We may have a simple and secure rule for case a).
> > >The certificateIssuer extension from a certificate is defined as :
> > >
> > > certificateIssuer ::= GeneralNames
> > >
> > >with
> > >
> > > certificateIssuer ::= GeneralNames
> > >
> > >with
> > >
> > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> > >
> > >In that case the name(s) contained in certificateIssuer MUST be
> > >certified by the CA that has issued the certificate where the
> extension
> > >appears.
> > >
> > >This means that the CRL Issuer can only be nominated by the CA that
> has
> > >issued the certificate.
> > >
> > >Denis
> >
> >
>