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

From: "Julien Stern" <[email-masked]>
Date: Mon, 3 Jul 2006 19:43:11 +0200

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

---

From: "Kemp David P." <[email-masked]>
Date: Mon, 3 Jul 2006 15:45:19 -0400

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,

Suppose that I have:

Regards,

--
Julien Stern

---

From: "Dave Engberg" <[email-masked]>
Date: Mon, 3 Jul 2006 16:00:18 -0400

Re: OCSP delegation & revocation ...

Revocation of a delegated responder cert is an underspecified area.  From
what I've seen in various OCSP relying party software, you won't get
consistent behavior unless you put in the id-pkix-ocsp-nocheck extension
into your responder's cert.

In that case, revocation won't be checked, and the responder's cert should
be appropriately short lived (e.g. a week or a month) so it will expire on a
similar timeline as the equivalent CRL.  There's no technical reason why the
responder certs couldn't be extremely short lived (e.g. one day), although
this would require you to do a little work at your CA to automate the
reissuance.

-----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:
 
Every certificate emitted by this CA contains the CRLDP extension indicating
who is the CRL issuer.

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

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 4 Jul 2006 09:48:32 +0800

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 Wang

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 10:44:48 +0200

> 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

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 10:36:12 +0200

David,

thank you for your reply.
I did felt that my scenario was "broken" in some sense.

However, this seem to imply that at the top-level, one needs a Trust
Anchor that does NOT delegate CRL production (at least if you always
want to be able to revoke everything but the TA).

A TA private key should typically be very complex to access and
manipulate for obvious security reasons, but now it should also produce
CRLs regularly, which can be a bit impractical...

Regards,

--
Julien

---

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

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

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: "Wen-Cheng Wang" <[email-masked]>
Date: Tue, 4 Jul 2006 18:42:28 +0800

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.

Wen-Cheng Wang

----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 5:40 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> 
> On Tue, Jul 04, 2006 at 05:17:46PM +0800, Wen-Cheng Wang wrote:
>> Julien,
>> 
> 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
>

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 11:40:12 +0200

Wen-Cheng,

Regards,

--
Julien Stern

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 4 Jul 2006 14:10:40 +0200

> In that sense,  RFC 3280bis is compliant with the ITU-T X.509

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]>
Date: Tue, 4 Jul 2006 14:27:07 +0200

> this would require you to do a little work at your CA to automate the

Dave,

It can be more than a little work if your CA is offline and has very
strict procedural control around the access to the private key.

I agree that the problem is not at all technical but more practical. A
Root CA (e.g. Trust Anchor) cannot be revoked, so any access to the
Root CA key should be controlled under much more stringent conditions
than the rest.

Having to access this key every day (or even every week) can be quite
unpractical. However, I agree that producing CRL or renewing the OCSP
responder certificate would both require access to the Root private key.

As Denis pointed out, pre-production of either the short lived
certificates or the CRL could be performed once, but then the problem
of the protection of this pre-produced material arises.

Regards,

--
Julien

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 04 Jul 2006 14:05:43 +0100

> just be common sense...).

On the subject of IDP. I've come across cases where the IDP extension is
present, critical but with all optional fields not present and
everything has a default value: i.e. it is just an empty SEQUENCE.

Is this legal?

AFAICS there is nothing that specifically forbids this but such an
extension AFAICS doesn't serve a useful purpose other than to break
implemenations which don't process IDP.

Steve.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 5 Jul 2006 16:04:07 +0800

It seems that the current texts of X.509 and RFC3280bis do not
prohibit a CA from issuing a CRL with an empty IDP extension
present, although I think it is not a good idea to issue such
unusual CRL.

However, a CRL with an empty IDP extension is semantically
interpretable. I believe that it is semantically equal to a CRL
with the IDP extension absent.

I repeat the interpretation here: 

Since the the IDP is absent, it is a full CRL because there is no
DistributionPointName. That is it is not a partitioned CRL (a.k.a. a CRL
distribution point).

Its scope covers both EE certificates and CA certificates issued by
the CA, bacause by default onlyContainsUserCerts = FALSE
and onlyContainsCACerts = FALSE.

Its scope covers all revocation reasons, because onlySomeReasons
is absent.

It has to be issued by the CA itself (i.e., a direct CRL) bacuase by
default indirectCRL = FALSE.

Wen-Cheng Wang

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 5 Jul 2006 15:49:45 +0800

Please see my opinions in-line.

Wen-Cheng Wang

----- Original Message ----- 
From: "Julien Stern" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 8:10 PM
Subject: Re: Question about indirect CRLs (and designated OCSP responders)

> information for the CRL issuer cert otherwise).

As Santosh pointed out if the IDP is absent, then it must be a direct full CRL
that covers all EE certificates and CA certificates issued by the CA. However,
it can be a complete full CRL or a delta CRL based on a complete full CRL,
depending on the presence of the deltaCRLIndicator extension.

To elaborate further:

According to X.509, a full CRL means "a CRL that contains entries for all
certificates that have been revoked for the given scope".

> just be common sense...).
I believe that it is legal. Nothing prohibits a CA from issuing a complete
full CRL and issuing its partitions at the same time. However, it is the
responsibility for the CA to make sure each partitioned CRL cover
the correct scope.

Wen-Cheng Wang