Subject: RE: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 27 Oct 2004 13:44:06 +0100

I disagree,

The problem to determine that a CRL is the correct CRL for a certificate
is a completely separate and independent problem to the issue to
discover a factual certification path to a particular CRL in order to
validate its signature.

These can, and probably should, be solved independently.

The task to allow AIA as a CRL extension in its current form does not
have to be on hold in the meanwhile. There are strong reasons enough to
see it through.

This relates to real practical problems. In our efforts, as implementer,
to work with indirect CRLs, we must in some cases rely on either AIA in
CRLs or a similar, currently non-standardized method. SIA doesn't solve
our needs. AIA does. It seems to me that other implementers have reached
the same conclusion. 

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 27 oktober 2004 14:24
> To: Stefan Santesson
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan,
> 
> > Denis,
> >
> > Yes, SIA could be an option in SOME cases, if properly implemented
and
> > if combined with an appropriate directory infrastructure.
> 
> You sentence is not correct.
> 
> "SIA could be an option in SOME cases, if properly implemented and if
> combined with an appropriate *repository* infrastructure".
> 
> > It's just not as generic and cost effective as AIA in CRLs,
especially
> > not when building chains from bottom up, which is a common way to
build
> > paths.
> 
> Of course since SIA is used to build chain top down ! (which is a
common
> way
> to build paths).
> 
> > I'm not trying to pick on words here. But for the first time I got
the
> > impression that you accept AIA in CRLs as a valid option.
> 
> Not exactly. AIA in CRLs COULD be a valid option.
> 
> > Do you still claim that AIA in CRLs is an invalid option that should
NOT
> > be allowed?
> 
> I never claimed such a sentence, so I do not need to disclaim it. :-|
> 
> Before accepting AIA as a valid option for CRLs we have to say how and
> when
> it would be used. The issue is MUCH MORE complicated than simply
adding
> AIA
> in CRLs, since we have to give the processing rules for that
extension.
> 
> Upon this aspect, we are far from an agreement and this is of course
> strongly related to the (lack of a) CRL processing model.
> 
> So we need first to say how we verify that a CRL Issuer is the right
CRL
> Issuer (see my e-mail fom this morning to Santosh). Once we will have
> fixed
> that, then we will be able to explore the advantages and disavantages
of
> including or not AIA in CRLs.
> 
> Denis
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Oct 2004 14:59:42 +0200

Stefan,

> I disagree,
   So we disagree.

> discover a factual certification path to a particular CRL in order to

No. The issue is who provide that extension and in which case or case(s).
Then what kind of use RPs are expected to do with it.

We already have too many extensions where different people have different 
interpretations of their use and thenafter justify an architecture by the 
presence of that extension ! or because "nothing prevents to make a given 
interpretation" of the document.

> to work with indirect CRLs, 

Are you claiming that this is only needed for indirect CRLs ?

(i.e. for CRLs which include certificates issued by authorities other than 
the CRL issuer).

> we must in some cases rely on either AIA in CRLs or a similar, currently 
 > non-standardized method.

> SIA doesn't solve our needs. 

This has never been demonstrated, and before knowing the solution, it would 
be nice to know what the problem is.

Denis

 > AIA does. It seems to me that other implementers have reached
> the same conclusion.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 27 Oct 2004 16:23:07 -0400

Denis, 

See responses in-line in [SC:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Wednesday, October 27, 2004 9:00 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs

Stefan,

   So we disagree.

> The problem to determine that a CRL is the correct CRL for a 
> certificate is a completely separate and independent problem to the 
> issue to discover a factual certification path to a particular CRL in 
> order to validate its signature.

[SC: Just like AIA in certificates, those who want to use it, will use it.
Others are welcome to use other means.]

[SC: We are not adding an extension.  We are permitting an existing
non-critical extension in the CRL for those who wish to use it.]

> have to be on hold in the meanwhile. There are strong reasons enough 
> to see it through.

> This relates to real practical problems. In our efforts, as 
> implementer, to work with indirect CRLs,

[SC: It is useful for both and may be more useful in the case of indirect
CRL]

[SC: Lot of extensions such as AKID, SKID, etc., are for efficiency reasons.
Since, AIA provides efficiency, there is no particular reason to prove other
ways.  If you think other ways are more efficient, do prove it.]

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 27 Oct 2004 16:18:19 -0400

Stefan,

For most parts, I agree with you.

In the interest of efficiency one can use the path matching algorithm to
guide building the certification path for the CRL issuer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, October 27, 2004 8:44 AM
To: Denis Pinkas
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs

I disagree,

The problem to determine that a CRL is the correct CRL for a certificate is
a completely separate and independent problem to the issue to discover a
factual certification path to a particular CRL in order to validate its
signature.

The task to allow AIA as a CRL extension in its current form does not have
to be on hold in the meanwhile. There are strong reasons enough to see it
through.

This relates to real practical problems. In our efforts, as implementer, to
work with indirect CRLs, we must in some cases rely on either AIA in CRLs or
a similar, currently non-standardized method. SIA doesn't solve our needs.
AIA does. It seems to me that other implementers have reached the same
conclusion. 

/Stefan

and
especially
build
common
the
NOT
> when it would be used. The issue is MUCH MORE complicated than simply
adding
extension.
CRL
> fixed that, then we will be able to explore the advantages and 
> disavantages
of