[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: 3280bis: CRL validation

To: <ietf-pkix@xxxxxxxx>
Subject: RE: 3280bis: CRL validation
From: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
Date: Wed, 15 Jun 2005 09:55:19 -0400
Importance: Normal
In-reply-to: <BF9309599A71984CAC5BAC5ECA629944029F6133@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx

Stefan,

I was having this discussion for the direct CRL.  As to indirect CRL, I did
not tighten up the algorithm since neither X.509 nor 3280 have any
constraints.

In order to secure Indirect CRL, there need to be trust constraints.  My
suggestions will be do that if existing implementations do not break.  I am
only familiar with one implementation and that will not break.

My suggestion will be to follow (in name only and not in key material) what
some of the leading OCSP client vendors do and that is:

Indirect CRL can be a trust anchor, issued a certificate by the trust
anchor, or issued a certificate by the delegating CA.  In the last case of
delegating CA, non-check extension should be permitted.

If the community agrees on these trust constraints, the algorithm can
accommodate this and make the indirect CRL processing secure.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 15, 2005 6:49 AM
To: Santosh Chokhani; ietf-pkix@xxxxxxxx
Subject: 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
> >
> >
>

References:
- RE: 3280bis: CRL validation
  - From: Stefan Santesson

Prev by Date: RE: 3280bis: CRL validation
Next by Date: RE: 3280bis: CRL validation
Previous by thread: RE: 3280bis: CRL validation
Next by thread: Re: 3280bis: CRL validation
Index(es):
- Date
- Thread