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

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

Stefan,
My replies have [Denis] in front of them.
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).
[Denis]  I disagree. Before the "validation engine" there is the "path construction engine". Depending upon whether key rollover has been or has not been performed by the relying party, one or two certificates may be needed. If the CRL issuer is servings multiple CAs, then a couple of certificates are needed for each CA. If we define a new extension, it MUST also be usable for a single CRL issued for different CAs.
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).
[Denis] Ahhhhh! you just crossed the line: a bag of certificates !
 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.
[Denis] You will need to transfer that bag of certificates every time. This is not good. Instead of trying to convince that the initially proposed solution is the best, please take some time to consider the benefits and drawbacks of the other solution I proposed.
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.
Denis 

Stefan Santesson
Senior Program Manager
Windows Security, Standards
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 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 16:41:29 +0100

Denis,

When this is not a good solution to your problem, then don't use it.

Why MUST is be bad to send the certs with every CRL if the alternative
is to go out on the network and fetch the certificates using extra
cycles.

I may use the same CRL 100+ times before it expires for many different
certificates. We send certificates with every OCSP response and we don't
consider that a problem. 

Stefan Santesson

Senior Program Manager

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

________________________________

Stefan, 

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

[Denis]  I disagree. Before the "validation engine" there is the "path
construction engine". Depending upon whether key rollover has been or
has not been performed by the relying party, one or two certificates may
be needed. If the CRL issuer is servings multiple CAs, then a couple of
certificates are needed for each CA. If we define a new extension, it
MUST also be usable for a single CRL issued for different CAs.

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.

[Denis] You will need to transfer that bag of certificates every time.
This is not good. Instead of trying to convince that the initially
proposed solution is the best, please take some time to consider the
benefits and drawbacks of the other solution I proposed.

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.

Denis 

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

________________________________

________________________________

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 19 Sep 2006 11:15:10 +0200

Stefan,

if I may jump in. Sometimes, it IS a problem to send certificates with
OCSP responses. We have at least one example where we will have to use
OCSP responses without certificates due to size contraints.

Admitelly, this case is rare, but there are scenarios where OCSP or
CRL size matters :)

What would you think of having a standard way to request (and send)
the certificate(s) associated to a CRL without bundling them.

One example (probably not the best but...) could be

http://www.xxx.com/thecrl.der  --> Gives the bare CRL
http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate,
followed by the bare CRL (so that you can stream).

Regards,

--
Julien

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 19 Sep 2006 15:55:01 +0200

> followed by the bare CRL (so that you can stream).
Or if I dare come back with my p7c solution which I do not actually have 
time (nor really intend as is) to argument for :
http://www.xxx.com/thecrl.der?x-pkcs7-crl --> Gives the crl  in pkcs#7, 
including optional certificates if you want

Ugly as it is, it has one big point going for it, it's already 
implemented. One fast  test gives me 51 bytes overhead, it's not that 
terrible wrt all those not really useful extensions some certificates have.
*
*