RE: 3280bis: CRL validation

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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
> 
>