Subject: Re: Question about indirect CRLs (and designated OCSP responders)

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 4 Jul 2006 10:18:59 +0200

I am glad that this problem was raised again.

>In my opinion, in approach (1), the certificate for the CRL issuer
>should contain a CRLDP that points to the special CRL
>that covers only that one certificate. In addition, the special CRL
>should contain an IDP that matches the CRLDP in the certificate.

This is fine. The current draft is currently missing guidance to handle that case.
Additional text, should be provided so that implementations can really 
support *in an interoperable way* the case where the CA is not handling 
revocation status information for all the certificates it issues.

Denis

>Wen-Cheng Wang
>
>----- Original Message ----- 
>From: "Kemp David P." <[email-masked]>
>To: "Julien Stern" <[email-masked]>; <[email-masked]>
>Sent: Tuesday, July 04, 2006 3:45 AM
>Subject: RE: Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> 
>> Julien,
>> 
>> There is a logical fallacy in your supposition which leads to
>> the problem you describe.  If the CA wishes to retain the
>> authority for deciding whether the CRL issuer is reliable, it
>> cannot delegate that authority to the CRL issuer.
>> 
>> The CA could use at least two approaches to avoid the problem:
>> 
>> 1) produce a certificate for the CRL issuer that does not
>> contain a CRLDP, and produce a CRL that covers only that one
>> certificate (and would therefore nearly always be empty).
>> 
>> 2) produce a certificate for the CRL issuer with a very
>> short validity period, refreshing the certificate for as
>> long as the CRL issuer remains reliable, and rekeying it
>> occasionally.
>> 
>> Any approach must begin with a goal to be accomplished,
>> and then derive from that goal the syntax used to implement
>> it.  Garbage goals in, garbage certificates out.
>> 
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Julien Stern
>> Sent: Monday, July 03, 2006 1:43 PM
>> To: [email-masked]
>> Subject: Question about indirect CRLs (and designated OCSP responders)
>> 
>> 
>> Folks,
>> 
>> I have a question regarding the treatment of Indirect CRLs in the
>> following case:
>> 
>> Suppose that I have:
>> - one CA (that does NOT produce CRLs)
>> - one CRL issuer (that produces CRLs on behalf of that CA)
>> 
>> Every certificate emitted by this CA contains the CRLDP extension
>> indicating who is the CRL issuer.
>> 
>> Now, also suppose that the CRL issuer certificate is emitted by the CA,
>> which can be useful in order to bring trust to this certificate.
>> 
>> It then seems that the CRL issuer can revoke its own certificate.
>> What should be the treatment in this setting if the serial number
>> of the certificate of the CRL issuer appears in the CRL?
>> 
>> Additionally, if the CRL issuer is compromised, the CA could issue
>> a new CRL issuer certificate, and the new CRL issuer could revoke
>> the certificate of the previous CRL issuer. But then what to do if the
>> old compromised CRL also revokes the new CRL issuer certificate?
>> It this setting simply not allowed for CRLs? If not, by what?
>> 
>> 
>> Also, I have exactly the same question regarding OCSP in the case
>> of a "CA Designated Responder" (RFC2560, page 2). This setting is
>> exactly the same as described above.
>> 
>> What happens if the OCSP responder responds that its own certificate is
>> revoked?
>> 
>> What happens if I am presented (say in a long time archive) with two
>> OCSP replies, each containing a "CA Designated Responder" certificate
>> which revokes the other one?
>> 
>> 
>> Regards,
>> 
>> --
>> Julien Stern
>> 
>> 
>>
>
>

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 4 Jul 2006 05:57:34 -0700

I encourage you all to read a refereed paper we presented on the
circularity in revocation at 2006 NIST PKI research conference.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, July 04, 2006 4:19 AM
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP
responders)

>should contain an IDP that matches the CRLDP in the certificate.

This is fine. The current draft is currently missing guidance to handle
that case.
Additional text, should be provided so that implementations can really 
support *in an interoperable way* the case where the CA is not handling 
revocation status information for all the certificates it issues.

Denis

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 4 Jul 2006 06:28:44 -0700

The rule is very simple when IDP is absent.

It is a full direct CRL, base or delta (depending on the presence of the
deltaCRLIndicator extension).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Tuesday, July 04, 2006 8:11 AM
To: [email-masked]
Subject: Re: Question about indirect CRLs (and designated OCSP
responders)

On Tue, Jul 04, 2006 at 06:42:28PM +0800, Wen-Cheng Wang wrote:
> 
> IDP is mandatory for a partitioned CRL and the relying
> party must check whether it match CRLDP. This is true
> even if it is a 'direct' CRL. Otherwise, there will be
> a risk that a man-in-the-middle repalces the partitioned
> CRL with other partitioned CRL issued by the same
> CA (or the same CRL issuer).
> 
> I think the Technical Corrigendium 3 of the ITU-T X.509
> standard is very clear about this. (Please see its corrigendium
> to section B5.1.4)
> 
> Section 5.2.5 of RFC 3280bis says:
> 
>   If the distributionPoint field is absent, the CRL MUST contain
>   entries for all revoked unexpired certificates issued by the CRL
>   issuer, if any, within the scope of the CRL.
>
> In that sense,  RFC 3280bis is compliant with the ITU-T X.509
> standard.

Thank you for the references.

Altough, in order to nitpick a bit, what is the rule if the IDP
is absent? This section refers to the situation where an IDP
is present. In that case, I agree that a distributionPoint must
be present unless there is a single CRL issuer (which should probably
then be the CA, because as you pointed the CA must provide revocation
information for the CRL issuer cert otherwise).

But what if there is
- One CRL with an IDP and a distributionPoint
- One CRL without an IDP

Is that "legal"? I did not find anything in RFC3280 (or son-of)
that forbides it, but I might have missed something (or it could
just be common sense...).

Regards,

--
Julien Stern

> From: "Julien Stern" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 04, 2006 5:40 PM
responders)
> 
> 
> >
> >On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
> >>Julien,
> >>
> >>Yes, it leaves us two CRL issuers. One is the delegated (indirect)
CRL
> >>issuer, and the other is the CA itself.
> >>
> >>The CA itself is responsible for revoking the certificate for the 
> >>delegated
> >>CRL issuer. Therefore, the CA still need to issue a special CRL that
> >>at least cover the certificate for the delegated CRL issuer. In that
case,
> >>the certificate should contain a CRLDP and the special CRL should
> >>contain an matched IDP, since the special CRL is a partitioned CRL
> >>(or offically called a CRL distribution point in the ITU-T X.509 
> >>standards).
> >
> >Wen-Cheng,
> >
> >I'm a bit confused about that part: my understanding was that you did
> >not need an IDP for "direct" CRL (and this special CRL is directly
> >produced by the CA). It is just "nicer" to put it for some reason,
> >or is it mandatory because the CRL is partitioned?
> >
> >Regards,
> >
> >--
> >Julien Stern
> >
> >>The delegated CRL issuer is responsible for revoking all
certificates
> >>issued by the CA other than the certificate of itself.
> >>
> >>BTW, in the case where a CA delegate its revocation responsibility
to
> >>an OCSP responder instead of a delegated CRL issued, the same
> >>approach can also be used to revoke the certificate for the OCSP
> >>responder if it is not a short-lived certificate.
> >>
> >>What I want to emphasize is that it is inevitable that a CA still
need
> >>to issue CRLs even it has delegated its revocation responsibility to
> >>a delegated CRL issuer or an OCSP responder, unless the certificate
> >>for the delegated CRL issuer or the OCSP responder is a short-lived
> >>certificate.
> >>
> >>Regards,
> >>Wen-Cheng Wang
> >>
> >>From: "Julien Stern" <[email-masked]>
> >>To: <[email-masked]>
> >>Sent: Tuesday, July 04, 2006 4:44 PM
responders)
> >>
> >>
> >>>
> >>>On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
> >>>Wen-Cheng,
> >>>wouldn't that leave us with two (delegated) CRL issuers for the CA
?
> >>>And then how to revoke the second delegated CRL issuer ? :)
> >>>
> >>>Regards,
> >>>
> >>>--
> >>>Julien
> >>>
> >>>>Wen-Cheng Wang
> >>>>

---

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 5 Jul 2006 18:48:19 +0200

>Denis,
>
>How could a relying party know that no CRL is available for
>short-lived certificates?
>
>Yes, this is an interesting question.
>
>Two options come across my mind.
>
>Option 1 is to introduce a certificate extension similar to the
>id-pkix-ocsp-nocheck extension defined in RFC 2560.

>Option 2 is letting the validity period of the short-lived
>certificates equal to the update period of the CRL. That is
>letting the notBefore of the certificate equal thisUpdate of the
>CRL and  letting the notAfter of the certificate equal
>nextUpdate of the CRL. The relying party has to be smart
>enough to know that since the validity period of the
>short-lived certificates is equivalent to the period of
>the updated revocation info is given by the CA to
>the delegated CRL issuer, it is reasonable that there is no
>need to check the revocation status of the short-lived
>certificates.

The main disadvantage is that there would the need to fetch a CRL 
to know this, while option 1 avoids to fetch it.

Option 1 is simple and only mandates the definition of an OID for that extension.

What is more difficult, is the writing of a full story when the CA delegates the 
issuance of CRLs. Using this would allow to increase the protection of root keys.
This would be a major benefit.

Denis

>Obviously, adopting option 2 might cause ambiguity, but
>it has the advantage that there is no need to introduce
>a new extension.
>
>Regards,
>Wen-Cheng Wang
>
>From: "Denis Pinkas" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 04, 2006 6:10 PM
>Subject: Re:Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> 
>> I jump into this interresting discussion.
>> 
>>>Julien,
>>>
>>>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>> In case, the CA handles the revocation of the CRL issuer(s).
>> Otherwise, it can issue short-lived certificates.
>> 
>>>The CA itself is responsible for revoking the certificate for the delegated
>>>at least cover the certificate for the delegated CRL issuer. In that case,
>>>(or offically called a CRL distribution point in the ITU-T X.509 standards).
>>>
>>>The delegated CRL issuer is responsible for revoking all certificates
>>>BTW, in the case where a CA delegate its revocation responsibility to
>>>What I want to emphasize is that it is inevitable that a CA still need
>> Yes, these are the two options.
>> 
>> - If CRLs are used, then a probably empty CRL would need to be issued each day.
>> 
>> - If short-lived certificates are used, then a new CRL Issuer certificate would need 
>>   to be issued each day. However in that case how could a relying party know 
>>   that no CRL is available ? 
>> 
>> For attribute certificates (AC) we have a way to indicate that no CRL is available, 
>> we would need a similar indication for public key certificates (PKC).
>> 
>> Note : such CRLs and short-lived certificates could be issued in advance and 
>> but only released every day in order to reduce the root key exposure.  
>> 
>> Denis

---

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 5 Jul 2006 18:48:19 +0200

Denis