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

Re: Signer certificate discovery for CRLs




Santosh,


See responses in-line in [DP:]

(text deleted)

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.

[SC: The issue is simple and straightforward.  Just the way signed CMS
permits to carry signer's certificate, AIA in CRL simply points to the
signer certificate.  You can use that pointer and develop the path whichever
way you like]

Upon this aspect, we are far from an agreement and this is of course
strongly related to the (lack of a) CRL processing model.

[SC: What specifically do you disagree with and why?  There is a CRL
processing model.  It is well articulated in X.509 Annex B and well
summarized in 3280]

[DP: There is no CRL processing model. It is not summarized in 3280.
This is a major problem of 3280].

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.

[SC: We have done this in this thread and by the briefing.]

[DP: No. We still need to say how we verify that a CRL Issuer is the right CRL Issuer]. I fear a myriad of different models.

Denis

PS: David, I copied this message to you since you are making a list of issues related to RFC 3280. This is certainly a major one: clarification on CRL processing when the CRL Issuer is not the CA that has issued the certificate is needed.

> /Stefan