Subject: RE: Signer certificate discovery for CRLs

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 26 Oct 2004 12:17:30 +0100

Denis,

<snip>
> Use of AIA in CRLs would be one way to do it, while the use of SIA
> in CA certificates is the other way.
>

I'm pleased to read that you acknowledge AIA in CRLs as a valid option.
That is all I ask for.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 22 oktober 2004 16:37
> To: Stefan Santesson; Santosh Chokhani
> Cc: pkix
> Subject: Re: Signer certificate discovery for CRLs
> 
> Stefan and Santosh,
> 
> > Denis,
> 
> > Thanks for the collection of relevant quotes.
> 
> > The case described may be odd but as far as I know, not violating
any
> > current text in RFC 3280 or X.509.
> 
> > A CA nominates a CRL by information in the CDP extension in the
cert,
> > not by issuing a cert to the CRL issuer. Where can you find that the
> > latter is a requirement? At least not in any of the sections you
quote.
> 
> > Regardless of this, the truth expressed by Santosh stands. Use of
AIA in
> > CRLs is more generic and provides less coding complexity.
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> 
> Conformity of CRL revocation checking to RFC 3280 through vagueness
> (your argument saying the content of the document does not violate
> any current text) is not the way to guaranty interoperability.
> 
> The description present in the document shall be sufficient to allow
> two different implementation to interoperate.
> 
> RFC 3280 is supposed to be a "standards track" document which means
> that it has also to conform with the draft standard requirements
> expressed in RFC 2026, which are:
> 
> 4.1.2  Draft Standard
> 
>     A specification from which at least two independent and
interoperable
>     implementations from different code bases have been developed, and
>     for which sufficient successful operational experience has been
>     obtained, may be elevated to the "Draft Standard" level.  For the
>     purposes of this section, "interoperable" means to be functionally
>     equivalent or interchangeable components of the system or process
in
>     which they are used.
> 
> (..)
> 
>     A Draft Standard must be well-understood and known to be quite
>     stable, both in its semantics and as a basis for developing an
>     implementation.
> 
> RFC 3280 is supposed to be a standards track document which means,
> according to RFC 2026, that :
> 
>     A Proposed Standard should have no known technical omissions with
>     respect to the requirements placed upon it.
> 
> However CRL processing has technical omissions which should be fixed.
> 
> Since Tim is listening and asking for agenda topics, revision of RFC
3280
> should be a top priority item on the list.
> 
> It is time to start the writing of a document which summarizes all
> the candidate changes which should be done to RFC 3280.
> 
> In addition, the "truth expressed by Santosh" does NOT stand.
> Use of AIA in CRLs would be one way to do it, while the use of SIA
> in CA certificates is the other way.
> 
> Denis

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Oct 2004 09:31:30 +0200

Stefan,

> I'm pleased to read that you acknowledge AIA in CRLs as a valid option.

I'm pleased to read that you noticed that AIA *would be an option* since I 
used "would be" in the case of AIA and "is" in the case of SIA:

Use of AIA in CRLs *would be* one way to do it, while the use of SIA
in CA certificates *is* the other way.  :-)

Denis