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

From: Sharon Boeyen <[email-masked]>
Date: Mon, 18 Sep 2006 10:08:00 -0400

A further concern with putting certificate(s) in CRLs really is the impact
of the size of the CRL on network load. Although this might be ok on a LAN -
what about a wireless segment or the connection between a CA and its ISP? In
practice, we find that often partitioned CRLs are no larger, or only
slightly larger than an OCSP response. Even adding one certificate could
make that CRL at least 3 times larger. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Monday, September 18, 2006 9:25 AM
To: 'Stefan Santesson'; Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

With respect to indirect CRLs I can see some utility to this feature, for
hopefully just a single certificate (and then use pointers in that
certificate to build the path if there are more differences between that
path and the one used for the certificate being validated). I don't fully
understand the other situation you are proposing this for though and think I
would be uncomfortable if this extension became widely used for environments
other than indirect CRLs. If this is a wider problem that indirect CRLs, I
think I'm leaning to the approach of bundling the CRL with the bag of certs
in a separate structure, enabling environments that have no problems
building paths today without this new feature to continue doing what they do
today and not be forced with having a bag of certs added to common CRLs.
However I do admit to not fully understanding the problem you are stating so
these are just my current thoughts.
 
Cheers,
Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, September 18, 2006 8:48 AM
To: Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

BM__MailEndComposeHi 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

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:32:29 +0100

Sharon,

Yes, this applies only to CRLs issued by a different key than the target
certificate. The case it may be used is for indirect CRLs and for CRLs
issued by a re-keyed CA.

In both cases there might be situations where you need more than 1
certificate to link back to the path of the target certificate. For
indirect CRLs if the trust in the CRL issuer is provided not by the
target CA but a parent to the target CA. For the re-keyed CA case of you
have don more than 1 CA re-key during the lifetime of the certificate.

Non of these cases are recommended practice, but we want to be able to
process them if customers choose this practice anyway for some reason.

We already have a structure for a bag of certificates (PKCS#7/CMS certs
only message) which already is used in cert storage so I would propose
using that format.

Finally regarding size. In most scenarios where this is a candidate
solution, the network load is simply not an issue. In cases where
network load is an issue you may not want to use this solution. This is
definitely not a mandatory feature. In scenarios where you use
pre-fetched CRLs and http proxy techniques for CRL distribution, the CRL
size increase will also be a negligible factor. In high latency (but
often high speed) networks this will be a great win due to fewer network
cycles (No need to go look for certificates).

Stefan Santesson

Senior Program Manager

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 18 september 2006 07:08
To: Sharon Boeyen; Stefan Santesson; Denis Pinkas; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

A further concern with putting certificate(s) in CRLs really is the
impact of the size of the CRL on network load. Although this might be ok
on a LAN - what about a wireless segment or the connection between a CA
and its ISP? In practice, we find that often partitioned CRLs are no
larger, or only slightly larger than an OCSP response. Even adding one
certificate could make that CRL at least 3 times larger. 

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
	Sent: Monday, September 18, 2006 9:25 AM
	To: 'Stefan Santesson'; Denis Pinkas; [email-masked]
	Subject: RE: Certs in CRLs - New standards task?

	With respect to indirect CRLs I can see some utility to this
feature, for hopefully just a single certificate (and then use pointers
in that certificate to build the path if there are more differences
between that path and the one used for the certificate being validated).
I don't fully understand the other situation you are proposing this for
though and think I would be uncomfortable if this extension became
widely used for environments other than indirect CRLs. If this is a
wider problem that indirect CRLs, I think I'm leaning to the approach of
bundling the CRL with the bag of certs in a separate structure, enabling
environments that have no problems building paths today without this new
feature to continue doing what they do today and not be forced with
having a bag of certs added to common CRLs. However I do admit to not
fully understanding the problem you are stating so these are just my
current thoughts.

	Cheers,

	Sharon 

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stefan Santesson
		Sent: Monday, September 18, 2006 8:48 AM
		To: Denis Pinkas; [email-masked]
		Subject: RE: Certs in CRLs - New standards task?

		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, 

		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, 

		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

________________________________

		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 volunteer to write a first draft if there is interest
from the group.

		Stefan Santesson

		Senior Program Manager

________________________________