Subject: RE: Certificates in CRLs

From: Sharon Boeyen <[email-masked]>
Date: Fri, 5 Jan 2007 09:09:25 -0500

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

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.

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]
<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]
<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-
<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-
<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: Stefan Santesson <[email-masked]>
Date: Tue, 9 Jan 2007 21:35:08 +0000

Sharon,

I'm not totally opposed to the idea of a package with a CRL and a certificate. But the solution is not as attractive to me.

The main reason is that the impact to the system design is greater.
If I summarize largely from your own mail, this includes;

1)      Expanded distribution configuration options in the CA.

2)      Possible enhancement to the CDP and/or AIA extension

3)      A new choice for the client (Which CRL object should I download)

4)      A new decoding procedure for CRL data (for bundled data)

5)      A new directory schema

I don't think the benefit gained here is substantial enough to defend all these modifications to the system and specifications.

The embedded certificate on the other hand only involves

1)      A new option in the CA to enable cert inclusion

2)      An optional component in clients to extract certificates from CRLs

Except from this the infrastructure is unaffected.

To the question what to do with the certificates. I view this is a matter of local policy. Any use of these certificates is optional. Looking this from our perspective, the certificates would simply be imported to the internal table of certificates from which the client attempts to construct a valid path. If the imported certificates are being used or not depends on the local optimization logic if alternative paths exist.

Stefan Santesson
Senior Program Manager

From: Sharon Boeyen [mailto:[email-masked]]
Sent: den 5 januari 2007 06:09
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
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.

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]] 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]]