Subject: Re: Certificates in CRLs

From: "Denis Pinkas" <[email-masked]>
Date: Wed, 14 Feb 2007 11:57:20 +0100

A way forward ?
 
The key issue is not the structure of the “augmented” CRL proposed by Stefan, 
but the ability to retrieve from a given CA either a CRL (i.e. the current 
structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed by Stefan), 
if a CA chooses to issue both. 
 
We need to focus on the cRLDistributionPoints extension to allow retrieving 
either a CRL, or a CRLwithCerts, or both.
 
Let us have a look at some sentences extracted from RFC 3280:
 
==========================================================================
 
   The cRLDistributionPoints extension is a SEQUENCE of
   DistributionPoint.  A DistributionPoint consists of three fields,
   each of which is optional: distributionPoint, reasons, and cRLIssuer.
 
(…)
 
   When the HTTP or FTP scheme is specified, the
   URI MUST point to a single DER encoded CRL as specified in [RFC
   2585].  HTTP server implementations accessed via the URI SHOULD
   specify the media type application/pkix-crl in the content-type
   header field of the response.  
 
   When the LDAP scheme is specified, the
   URI MUST specify a distinguishedName and attribute and SHOULD specify
   a host name (e.g., ldap://ldap.example.com/cn=exmplCA,
   dc=example,dc=com?certificateRevocationList;binary).  
 
(…)
 
   The URI MUST include
   an appropriate attribute description for the attribute that holds the
   DER [X.690] encoded CRL.
 
==========================================================================
 
A way forward would be to define appropriate attribute descriptions for 
the attributes that holds either the encoded CRL or the encoded CRLwithCerts. 
We could recommend to use currentCRL and currentCRLwithCerts, or latestCRL 
or latestCRLwithCerts.
 
For HTTTP or FTP a new media type could be defined such as 
application/pkix-crlwithcerts to be used in the content-type header field 
of the response. 
 
For LDAP, the query should end up, for example, with CRLwithcerts;binary/
 
We could also say that if the CA has chosen to issue both types of CRLs, 
then every distributionPoint holding a CRL (as defined today) should be placed 
first in the list.
 
Denis

I’m in agreement that Stefan’s proposal is a decent one.  As Phillip mentions, it certainly isn’t appropriate in every situation, but I can see situations in which it might be useful.  One might argue that a CRL issuer could issue two CRLs, the most commonly retrieved one without this extension, but a separate one issued with it—the latter being made to applications responsible for long term archive, historical signature validation, or other purposes which might find it useful.  
 
I don’t see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, non-critical, and does not affect path processing.  
 
--Peter
 
+----------------------------------------------------------------+
| Peter Hesse                     [email-masked]     |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
|       Visit our InfoSecurity blog: securitymusings.com         |
+----------------------------------------------------------------+
"The generation of random numbers is too important to be left
 to chance." --Robert R. Coveyou

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, February 13, 2007 6:53 PM
To: Sharon Boeyen; Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs
 
I think that Sharon's proposal might have been a good idea in 1995 before the world got wedged on CRLs as the revocation mechanism. We can define a package but its too late to get it embedded in the rest of the application infrastructure.
 
Given where we are Stefan's proposal is the best one. It is compatible with the existing infrastructure and solves a real issue. 
 
It is an option, clearly there are cases where it would be inappropriate but universal applicability has never been a requirement. Otherwise we could have saved all the time spent on attribute certificates.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sharon Boeyen
Sent: Friday, January 05, 2007 9:09 AM
To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs
Stefan I really don't think you can state where this will or will not be used in the future. Naturally you know where you want to use it, but software only enables a facility and the customer decides when and how to use it. 
 
Whether this scheme could possibly be useful in some cases is not my point. My point is that current deployments seem to be working fine without it and I don't want to see those interfered with just because some CA they may have cross certified with decided to put certificates inside their CRLS. Back to Denis' point - there is no need to impose this in the way you've proposed. 
 
Earlier I (and others including Dave Kemp) suggested a "package" that includes the CRL, and the certificate in question as an 'extra' that a CA could publish in addition to a regular CRL. That "package could be published in a separate directory attribute and/or an HTTP accessible file. It could be pointed to from within the certificate just as the CRL currently is. That could be done either by extending the CRLDP or adding a new pointer extension or adding a new method to the AIA extension. That type of approach gives you what you want but does not in any way interfere with clients who do not want and do not need to retrieve that bloated CRL. 
 
Also, you haven't addressed the question about what happens when more than one certificate is needed. If a CRL includes more than one certificate (e.g. the CRL issuer did one or more key rollovers then CRL gets bloated a lot bigger than you suggested. I don't want to debate how often a key gets rolled over either however I have definitely seen instances in real world deployments where a key has been rolled very often in a very short period of time (regardless of whether the reason for rolling it was a good one or not - it has happened). Also, regardless of the size of the "bloat" I'm saying that in most cases the clients will already have the certificates in question and this bloat will cause them extra processing in managing their certificate caches etc unnecessarily. The client should have a choice as to whether to download the certificate or not.
 
I don't understand why you're so opposed to the "package" solution. 
 
Cheers,
Sharon 
-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 8:01 AM
To: Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs
We are only talking about an extra 16K at most. The download time is the absolute most cases is negligible. 
For those cases where this solution makes sense, the network bandwidth issue is not a problem.
 
For the cases where this would be an issue, this solution would not be used.
 
On the contrary, in some networks and scenarios, this will improve performance. Especially in high latency networks with PKI based peer-peer authentication where an extra retrieval cost way more performance than the expanded CRL size.
 
Also, many clients are configured to pre-fetch CRL:s before they are used, using idle time on the network at no extra cost.

Stefan Santesson
Senior Program Manager
Windows Security, Standards
 
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 4 januari 2007 17:36
To: Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs
 
I still think wasted bandwidth is also an issue. Forcing the download of 'fat' CRLs on clients when, in many cases, those clients already have the certificates locally that caused the bloating of the CRL, is an unnecessary waste.
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson 
Sent: Wednesday, January 03, 2007 9:58 AM 
To: Russ Housley 
Cc: [email-masked] 
Subject: RE: Certificates in CRLs 
 
Russ, 
In theory, the CA can put different pointers to different CRLs in each certificate if some certificates are prime targets for frequent checking. But I don't think that is a common scenario.
My point is that in order to allow free selection of CRLs, you would have to add capability to the CDP extension rather than to the CRL. I don't think such effort is worth the trouble.
I'm convinced that including certs in a CRL will only be made in situations where it in the sum of all, helps increase efficiency and where the extra bandwidth consumed is not an issue.
I read the critique of this idea as not really be a bandwidth issue, but that some implementers simply don't want to be faced with the requirement to implement this feature. But I don't see that they have to. A CRL with certs in a non-critical extension should work just as well in current clients as any current CRL without certs. The extension can simply be ignored.
This is not a necessary feature, but a practical one offering performance improvements in some environments at no loss of interoperability.
 
Stefan Santesson 
Senior Program Manager 
Windows Security, Standards 
 
> -----Original Message----- 
> From: Russ Housley [mailto:[email-masked]] 
> Sent: den 21 december 2006 16:19 
> To: Stefan Santesson 
> Cc: [email-masked] 
> Subject: RE: Certificates in CRLs 
> 
> Stefan: 
> 
> If the CA chooses to offer both, how can the RP determine which one it 
> will get?  Does the CA post them in different LDAP attributes? 
> 
> Russ 
> 
> At 08:00 AM 12/21/2006, Stefan Santesson wrote: 
> 
> >As with anything else, the relying party can get what the CA offers. 
> > 
> >I don't think there is any realistic scenario where the CA has a 
> >reason to offer CRLs both with and without certificates. To offer 
> >this capability to RP is however not a matter for this protocol. It 
> >would be a matter for the CRL referencing model, i.e. CDP and/or 
> >directory schema. 
> > 
> >I don't think that extra complexity however is very useful. 
> > 
> >Stefan Santesson 
> >Senior Program Manager 
> >Windows Security, Standards 
> > 
> > 
> > > -----Original Message----- 
> > > From: [email-masked] [mailto:owner-ietf- 
> > > [email-masked]] On Behalf Of Denis Pinkas 
> > > Sent: den 20 december 2006 17:05 
> > > To: [email-masked] 
> > > Subject: Re: Certificates in CRLs 
> > > 
> > > 
> > > 
> > > It is necessary to provide relying parties with the choice to get 
> > > : 
> > > 
> > >   - CRLs "as usual", or 
> > >   - CRLs that carry that new extension. 
> > > 
> > > The current proposal does not allow for it. 
> > > 
> > > Until the draft is changed, I am against the addition of this work 
> item 
> > > to the program of the PKIX WG. 
> > > 
> > > Denis 
> > > 
> > > 
> ______________________________________________________________________ 
> _ 
> > > _______ 
> > > 
> > > >Since last IETF a new draft was posted: 
> > > >http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl- 
> 00.txt 
> > > > 
> > > >There is a request to add this draft to the PKIX work and I would 
> > > encourage to start the discussion about this decision in this 
> thread. 
> > > > 
> > > >Stefan Santesson 
> > > >Senior Program Manager 
> > > >Windows Security, Standards 
> > > 
> > > 
> > >

---

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Wed, 14 Feb 2007 10:03:17 -0500

I likewise agree with Peter, Phillip and Stefan.  The CRL bloat is not
large, and for those of us with large CRLs to begin with (can debate
separately why that circumstance exists...), the bloat is negligible.  Since
this is entirely optional; and since the owner of a CA therefore has full
discretion to include or not include the certs (and can do as Peter
described and published two virtually contemporaneous CRLs, one with and one
without, if needed to avoid breaking apps), it seems to me that this
approach can be used in a fashion which does not break anything, and it can
provide real value for archival purposes.

Richard A. Guida 
Director, Information Security 

Johnson & Johnson 
Room GS8217 
410 George Street 
New Brunswick, New Jersey  08901 
Phone:  732 524 3785 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Peter Hesse
Sent: Wednesday, February 14, 2007 12:05 AM
To: 'Hallam-Baker, Phillip'; 'Sharon Boeyen'; 'Stefan Santesson'; 'Russ
Housley'
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I'm in agreement that Stefan's proposal is a decent one.  As Phillip
mentions, it certainly isn't appropriate in every situation, but I can see
situations in which it might be useful.  One might argue that a CRL issuer
could issue two CRLs, the most commonly retrieved one without this
extension, but a separate one issued with it-the latter being made to
applications responsible for long term archive, historical signature
validation, or other purposes which might find it useful.  

I don't see any harm in adding this extension as an optional feature for
PKIs that wish it, since it is truly optional, non-critical, and does not
affect path processing.  

--Peter

+----------------------------------------------------------------+
| Peter Hesse                      [email-masked]
<mailto:[email-masked]>      |
| Phone: 703-378-5808 x105      Gemini Security Solutions, Inc.  |
|       Visit our InfoSecurity blog: securitymusings.com
<http://www.securitymusings.com/>          |
+----------------------------------------------------------------+
"The generation of random numbers is too important to be left
 to chance." --Robert R. Coveyou

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, February 13, 2007 6:53 PM
To: Sharon Boeyen; Stefan Santesson; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

I think that Sharon's proposal might have been a good idea in 1995 before
the world got wedged on CRLs as the revocation mechanism. We can define a
package but its too late to get it embedded in the rest of the application
infrastructure.

Given where we are Stefan's proposal is the best one. It is compatible with
the existing infrastructure and solves a real issue. 

It is an option, clearly there are cases where it would be inappropriate but
universal applicability has never been a requirement. Otherwise we could
have saved all the time spent on attribute certificates.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: Friday, January 05, 2007 9:09 AM
To: 'Stefan Santesson'; Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

Stefan I really don't think you can state where this will or will not be
used in the future. Naturally you know where you want to use it, but
software only enables a facility and the customer decides when and how to
use it. 

Whether this scheme could possibly be useful in some cases is not my point.
My point is that current deployments seem to be working fine without it and
I don't want to see those interfered with just because some CA they may have
cross certified with decided to put certificates inside their CRLS. Back to
Denis' point - there is no need to impose this in the way you've proposed. 

Earlier I (and others including Dave Kemp) suggested a "package" that
includes the CRL, and the certificate in question as an 'extra' that a CA
could publish in addition to a regular CRL. That "package could be published
in a separate directory attribute and/or an HTTP accessible file. It could
be pointed to from within the certificate just as the CRL currently is. That
could be done either by extending the CRLDP or adding a new pointer
extension or adding a new method to the AIA extension. That type of approach
gives you what you want but does not in any way interfere with clients who
do not want and do not need to retrieve that bloated CRL. 

Also, you haven't addressed the question about what happens when more than
one certificate is needed. If a CRL includes more than one certificate (e.g.
the CRL issuer did one or more key rollovers then CRL gets bloated a lot
bigger than you suggested. I don't want to debate how often a key gets
rolled over either however I have definitely seen instances in real world
deployments where a key has been rolled very often in a very short period of
time (regardless of whether the reason for rolling it was a good one or not
- it has happened). Also, regardless of the size of the "bloat" I'm saying
that in most cases the clients will already have the certificates in
question and this bloat will cause them extra processing in managing their
certificate caches etc unnecessarily. The client should have a choice as to
whether to download the certificate or not.

Cheers,

Sharon 

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 8:01 AM
To: Sharon Boeyen; Russ Housley
Cc: [email-masked]
Subject: RE: Certificates in CRLs

BM__MailEndComposeWe are only talking about an extra 16K at most. The
download time is the absolute most cases is negligible. 

For those cases where this solution makes sense, the network bandwidth issue
is not a problem.

On the contrary, in some networks and scenarios, this will improve
performance. Especially in high latency networks with PKI based peer-peer
authentication where an extra retrieval cost way more performance than the
expanded CRL size.

Also, many clients are configured to pre-fetch CRL:s before they are used,
using idle time on the network at no extra cost.

Stefan Santesson

Senior Program Manager

I still think wasted bandwidth is also an issue. Forcing the download of
'fat' CRLs on clients when, in many cases, those clients already have the
certificates locally that caused the bloating of the CRL, is an unnecessary
waste.

-----Original Message----- 
From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Stefan Santesson 
Sent: Wednesday, January 03, 2007 9:58 AM 
To: Russ Housley 
Cc: [email-masked] 
Subject: RE: Certificates in CRLs 

Russ, 

In theory, the CA can put different pointers to different CRLs in each
certificate if some certificates are prime targets for frequent checking.
But I don't think that is a common scenario.

My point is that in order to allow free selection of CRLs, you would have to
add capability to the CDP extension rather than to the CRL. I don't think
such effort is worth the trouble.

I'm convinced that including certs in a CRL will only be made in situations
where it in the sum of all, helps increase efficiency and where the extra
bandwidth consumed is not an issue.

I read the critique of this idea as not really be a bandwidth issue, but
that some implementers simply don't want to be faced with the requirement to
implement this feature. But I don't see that they have to. A CRL with certs
in a non-critical extension should work just as well in current clients as
any current CRL without certs. The extension can simply be ignored.

This is not a necessary feature, but a practical one offering performance
improvements in some environments at no loss of interoperability.

Stefan Santesson 
Senior Program Manager 

> From: Russ Housley [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > From: [email-masked] [ mailto:owner-ietf-
<mailto:owner-ietf->  
> > > to the program of the PKIX WG. 
<http://www.ietf.org/internet-drafts/draft-santesson-pkix-vccrl->

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Feb 2007 09:06:25 -0800

We could load these semantics into the CRL Distribution point but a simpler way to support them would be via the existing HTTP content negotiation mechanism (ACCEPT header). 
 
To do this all we need to do is to define the appropriate descriptions. A single distribution point resource identifier then serves for both resources.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
	Sent: Wednesday, February 14, 2007 5:57 AM
	To: [email-masked]
	Subject: Re: Certificates in CRLs

	A way forward ?

	The key issue is not the structure of the "augmented" CRL proposed by Stefan, 
	but the ability to retrieve from a given CA either a CRL (i.e. the current 
	structure of a CRL) or a CRLwithCerts (i.e. the new structure proposed by Stefan), 
	if a CA chooses to issue both. 

	(...)

	(...)

	   The URI MUST include

	   DER [X.690] encoded CRL.

	Denis
	 
________________________________

	I'm in agreement that Stefan's proposal is a decent one.  As Phillip mentions, it certainly isn't appropriate in every situation, but I can see situations in which it might be useful.  One might argue that a CRL issuer could issue two CRLs, the most commonly retrieved one without this extension, but a separate one issued with it-the latter being made to applications responsible for long term archive, historical signature validation, or other purposes which might find it useful.  

	I don't see any harm in adding this extension as an optional feature for PKIs that wish it, since it is truly optional, non-critical, and does not affect path processing.  

	--Peter

	|       Visit our InfoSecurity blog: securitymusings.com <http://www.securitymusings.com/>          |

________________________________

		Cheers,

		Sharon 

		-----Original Message-----
		From: Stefan Santesson [mailto:[email-masked]] 
		Sent: Friday, January 05, 2007 8:01 AM
		To: Sharon Boeyen; Russ Housley
		Cc: [email-masked]
		Subject: RE: Certificates in CRLs

			 

			Stefan Santesson

			Senior Program Manager

			-----Original Message----- 
			From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson 
			Sent: Wednesday, January 03, 2007 9:58 AM 
			To: Russ Housley 
			Cc: [email-masked] 
			Subject: RE: Certificates in CRLs 

			Russ, 

			Stefan Santesson 
			Senior Program Manager 

			> > > to the program of the PKIX WG. 

________________________________