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

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

I jump into this interresting discussion.

>Julien,
>
>Yes, it leaves us two CRL issuers. One is the delegated (indirect) CRL
>issuer, and the other is the CA itself.

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
>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).
>
>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.

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

>Regards,
>Wen-Cheng Wang
>
>----- Original Message ----- 
>From: "Julien Stern" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, July 04, 2006 4:44 PM
>Subject: Re: Question about indirect CRLs (and designated OCSP responders)
>
>
>> 
>> On Tue, Jul 04, 2006 at 09:48:32AM +0800, Wen-Cheng Wang wrote:
>>> 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.
>> 
>> 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
>>> 
>>> ----- 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: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 12:48:49 +0200

On Tue, Jul 04, 2006 at 12:10:00PM +0200, Denis Pinkas wrote:
> [snip]

General agreement with everyone on the two options.

> but only released every day in order to reduce the root key exposure.  

That note is definitely interesting. I'm precisely currently interested by
these issues.

Suppose that I'm operating a Root CA in a very secure environnement.
You know, in a bunker guarded by tanks and guards with machine guns,
and with the presence of 25 people required each time I want to perform
an operation with the Root private key (I'm kidding but you get the
point).

In that case, I do want to minimize access to this key.
It is then very tempting to pre-produce empty CRLs or short
lived-certificates, but isn't it "cheating"? That is, isn't the
exposure of this pre-produced CRLs and/or certificates a killer,
security wise? Shouldn't they be protected by essentially the same
level of security as the Root?

While they are not using any indirect CRLs, I had a quick look at the
"intermediate" CA in IE and I noticed that most of them did not include
any CRLDP (but we clearly not short lived). Those which included CRLDP
had a CRL validity period of several months.

Regards,

--
Julien

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 4 Jul 2006 19:15:33 +0800

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.

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)