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

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

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: "Santosh Chokhani" <[email-masked]>
Date: Mon, 18 Sep 2006 09:19:55 -0700

Before we get too far in this, can we all agree on what concern we are
addressing using this mechanism:

1.	Denial of Service
2.	Network Availability
3.	Security
4.	Response Time
5.	Something else
6.	Combination of the above

I find this mechanism of not great use for 1 and 3.  For 2, most
implementations get CRL from the Network.  It is quite disingenuous to
say that the network will be down after getting a CRL to follow the AIA.

________________________________

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

	
________________________________

---

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 19 Sep 2006 16:16:39 +0200

I support Sharon's position.

Denis

The more I think about this the more I dislike the approach of including certs in the CRL. There are currently implementations that are able to find all the paths they need with the current information in the CRL (by using the DN to do a directory lookup). I recognize this isn't always the simplest way to find information and I do support pointer schemes such as AIA and SIA or another pointer approach. However I really don't want to see the size of CRLs increased in the way they would be even if a single cert was added, whether that be for indirect CRLs, CA key rollovers or any other case. 
Stefan, its fine for you to say that implementers wouldn't need to support the new extension, however as soon as a CA starts putting it in there is an impact on all implementations because of the size of the CRL (regardless of whether an implementation decides to process or ignore the non-critical extension). 
Cheers, 
Sharon 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Stern 
Sent: Tuesday, September 19, 2006 5:15 AM 
To: [email-masked] 
Subject: Re: Certs in CRLs - New standards task? 

On Mon, Sep 18, 2006 at 04:41:29PM +0100, Stefan Santesson wrote: 
> 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, 
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 
  
> Sent: den 18 september 2006 06:10 
> To: [email-masked] 
> 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. 
> 
> represents the old or the new CA key or what the hash of the 
> [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 ! 
> 
> certificate if present) does not help the RP, we did not do any 
> [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 
> 
> 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 
> 
> 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 
> 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 
> 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. 
> 
> 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. 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 21 Sep 2006 03:58:46 -0700

Ryan,

Items 2 and 3 are not peculiar to CRL signer.  These are generic issues
and one can use these to argue that all the certificates and revocation
information required should be bundled as one.

Item 1, I think that given the CRL issuer certificate appears in the
same directory entry as the CRL and the CRL issuer can ensure the
availability of CRL on HTTP and certificate on HTTP AIA, I do not see it
as a practical issue.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 4:28 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I understand the point, and in-fact it is why I originally recommended
the same solution you call out bellow with AIA in certs pointing to a
p7c; however connectivity is not as much an constant as we often like to
think.

With that in-mind there are other related scenarios to keep in mind when
evaluating a solution here:
1) General connectivity problems, you may have access to the url in the
CDP to acquire the CRL but not have access (server down, url is internal
to network but rp is out of network, etc) to the CRLs issuer certificate
referenced in its AIA.
2) Unreliable network connectivity, with the increase in mobile hosts
the chances of the connectivity going down after getting the CRL but
before the intermediate has been retrieved.
3) API performance - When building a generalized certificate handling
API its often necessary to have a "contract" with your callers, e.g. I
will return in n seconds reliably in these cases its desirable to reduce
the number of sockets being created.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Wednesday, September 20, 2006 11:19 AM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Thanks to Ryan for providing the following definitions of Pre-IP and
Post-IP off list.

"Pre IP = Situations like establishing network connectivity or verifying
signatures in boot before network connectivity.
Post IP = Situations where host or user has full IP connectivity."

Using the above definitions, it does not seem that adding the extension
is a particularly good idea to solve the problem for the connectivity
challenged scenarios.  The following is my thinking:

The question is how did we get the CRL (indirect or for that matter
direct one) in the first place.  The CRL is stored as an attribute of
the CRL issuer and hence when the CRL is obtained, certificate can also
be obtained, obviating the need.

Another alternative is for the CA that issued a certificate and
delegated indirect CRL issuer, can put in its AIA p7c bag the
certification path for the indirect CRL issuer.

Now, whoever is doing pre-IP fetch of certificates and CRL and is
loading the cache can have all these certificates.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:13 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Hi Santosh - I think there are numerous benefits, for example:
1. Pre-IP scenarios that have the CRL but not the intermediates; more
likely in indirect cases.
2. Post-IP scenarios where all the intermediates and trust anchors' are
there except the indirect certificate so chain discovery must go online
to complete discovery; more likely in indirect cases.
3. Post-IP scenarios where no intermediates are present and the
implementing chain validation API must return in a specific time and the
allotted time is already used through other discovery and validation
phases, additional wire retrievals introduce more latency and should be
avoided if possible.

These are just a few off the top of my head, I am sure Stefan has
others.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: Tuesday, September 19, 2006 12:28 PM
To: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Ryan,

Can you explain why "without having to go on the wire" makes sense?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan Hurst
Sent: Tuesday, September 19, 2006 2:21 PM
To: Russ Housley; Jean-Marc Desperrier; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>Ryan Hurst wrote:
>>Have you considered the idea of introducing a new access method to the
>>AIA that would point to a P7c that possibly contained the CRL, its
>>issuers and maybe the certificates issuers?
>>
>I vote for p7c. Most CAs already include an option to distribute CRL
this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>When RFC 3280bis says that URIs inside a DistributionPointName must 
>point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just
>making explicit a rule that was already required for proper
interoperability ?