Subject: Re: Certs in CRLs - New standards task?

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 18 Sep 2006 09:51:13 +0200

Stefan,

I am not in favour of the proposed approach.

I have concern by always overloading the CRL, not simply with one additional certificate, 
but with two additional certificates, because of CA key rollover.

The situation will be even worse when a CRL issuer is trusted by more than one CA 
to issue CRLs.

Talking to you in your capacity of co-chair, I would like to recall that the full story 
of how to check a CRL that is not issued by a CA is still not crystal clear in 3280bis, 
and we should clarify that before. :-)

Talking to you as PKIX member, I would favor the use of  one extension with two pointers per CA:

 - one pointing to the current or old certificate still valid, and 
 - another one pointing the new or current certificate already valid. 

This will allow to fetch once the certificate(s) that is/are needed.

The AIA extension is not the right vehicule, since it cannot include a hash of the data that is pointed.
We should add a hash of the certificate, which would allow to make sure that the right certificate 
was obtained without the need to build and verify the certification path.

From the above observations, the problem is much more complex than originally presented.

Denis

Taking the pkix chair hat off and the vendor hat on
I’m asking this group to consider a new standards task to solve a real implementation issue with indirect CRLs and CRLs issued by a re-keyed CA. I.e. where the target certificate and it’s CRL are signed by different keys and the RP does not have access to the CRL Issuer certificate.
It is basically the same situation we solved with allowing the AIA extension in CRL’s namely the problem to obtain the CRL issuer’s certificate, alternatively, certificate path.
In our efforts to implement the AIA solution we have encountered some real issues.
1)       Each time we are forced to go out and retrieve new information on the network, we have a source of potential problems such as unavailable network resources, timeouts etc. It all adds to the validation time and harms the user experience.
2)       The AIA in CRL’s provide another opening for DoS attacks if rouge CRL’s point their AIA to a targeted web server. This is tough not as serious as the DoS problems with AIA in certificates, but this one we might avoid more easily.
 The proposed solution is to define a new CRL extension that may contain the CRL Issuer certificate (not just a URL to its location). Preferably this would be a PKCS#7 (or CMS) Certs only message that may contain a single certificate or a bag of certificates (a chain).
 While it wouldn’t be attractive to define such extension for certificates due to certificate size considerations, CRL’s are often of such size that including the certs needed to validate it only leads to an insignificant increase of size, while it may offer substantial processing advantages.
 I would like to hear the opinion of this group on this.
 I volunteer to write a first draft if there is interest from the group.
 
Stefan Santesson
Senior Program Manager
Windows Security, Standards

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 18 Sep 2006 13:47:52 +0100

Hi Denis,

Speaking as an implementer and from the experience from how our own
products work, the issue and the solution is much more simple than the
solution you propose.

The  validation engine does not need to know which certificate that
represents the old or the new CA key or what the hash of the certificate
is. The task of the validation engine for this issue is simply to
validate the signature of the CRL using a valid path to a trusted root
(being the same used to validate the target certificate).

First of all the validation engine will try to build a path using all
certs from the validated path and all cashed and locally stored
certificates and root keys. If this fails it could use the certs
provided in the CRL using this new extension (just a bag of certificates
with no specific information).

In the end, if the provided bag of certificates (typically only 1
certificate if present) does not help the RP, we did not do any
particular damage to the RP (just slightly increased the CRL), we just
couldn't help him and he will now have to try directory search etc as
before. But the fact is that by including certificate/s in the CRL we
may in many PKI configurations considerably help the RP.

I fully agree that this information can not be stored in an AIA. A new
CRL extension is needed.

Finally I don't agree to the term "overloading" here. We usually use
that term to describe when we stretch the semantics of existing fields
and name forms. This is just an new optional non-critical extension with
useful data, relevant to the processing of the CRL.

Stefan Santesson

Senior Program Manager

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 18 september 2006 00:51
To: [email-masked]
Subject: Re: Certs in CRLs - New standards task?

Stefan,

I have concern by always overloading the CRL, not simply with one
additional certificate, 

The situation will be even worse when a CRL issuer is trusted by more
than one CA 

to issue CRLs.

Talking to you in your capacity of co-chair, I would like to recall that
the full story 

of how to check a CRL that is not issued by a CA is still not crystal
clear in 3280bis, 

Talking to you as PKIX member, I would favor the use of  one extension
with two pointers per CA:

The AIA extension is not the right vehicule, since it cannot include a
hash of the data that is pointed.

We should add a hash of the certificate, which would allow to make sure
that the right certificate 

was obtained without the need to build and verify the certification
path.

From the above observations, the problem is much more complex than
originally presented.

Denis

________________________________

I'm asking this group to consider a new standards task to solve a real
implementation issue with indirect CRLs and CRLs issued by a re-keyed
CA. I.e. where the target certificate and it's CRL are signed by
different keys and the RP does not have access to the CRL Issuer
certificate.

It is basically the same situation we solved with allowing the AIA
extension in CRL's namely the problem to obtain the CRL issuer's
certificate, alternatively, certificate path.

In our efforts to implement the AIA solution we have encountered some
real issues.

1)       Each time we are forced to go out and retrieve new information
on the network, we have a source of potential problems such as
unavailable network resources, timeouts etc. It all adds to the
validation time and harms the user experience.

2)       The AIA in CRL's provide another opening for DoS attacks if
rouge CRL's point their AIA to a targeted web server. This is tough not
as serious as the DoS problems with AIA in certificates, but this one we
might avoid more easily.

 The proposed solution is to define a new CRL extension that may contain
the CRL Issuer certificate (not just a URL to its location). Preferably
this would be a PKCS#7 (or CMS) Certs only message that may contain a
single certificate or a bag of certificates (a chain).

 While it wouldn't be attractive to define such extension for
certificates due to certificate size considerations, CRL's are often of
such size that including the certs needed to validate it only leads to
an insignificant increase of size, while it may offer substantial
processing advantages.

Stefan Santesson

Senior Program Manager

________________________________