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

From: Sharon Boeyen <[email-masked]>
Date: Tue, 19 Sep 2006 09:16:30 -0400

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
 
> Stefan Santesson
> 
> Senior Program Manager
> 
> Windows Security, Standards
> 
> 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,
> 
> 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: Stephen Farrell <[email-masked]>
Date: Tue, 19 Sep 2006 19:38:47 +0100

I'm not sure myself. But I would like to see an individual I-D
before the WG adopted a work item.

S.

Sharon Boeyen wrote:
> 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
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Julien Stern
> 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 :)
> 
> http://www.xxx.com/thecrl.der?addcert  --> Gives the certificate, 
> followed by the bare CRL (so that you can stream).
> 
> Regards,
> 
> -- 
> Julien
>  
>  > Stefan Santesson
>  >
>  > Senior Program Manager
>  >

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Sep 2006 04:17:34 +0100

Sharon,

I'm not proposing a best practice document telling CAs to include
certificates in CRLs.
So please don't read this as proposing - "All CRLs MUST include
certificates"

But for some PKI implementations, having a standardized way to include
certificates would avoid many problems, especially when indirect CRL's
are used or in some scenarios with re-keyed CAs where revocation of old
certs is performed by the new CA key.
No RP need to understand or process this extension, No CA have to
include Certs in CRLs.

Would you still have a problem if a CA have the possibility to add
certificates to CRLs in cases where it make sense to do so?

Stephen,

I also think we have reached the point where an I-D is needed. I will
post one ASAP.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 19 september 2006 20:39
> To: Sharon Boeyen
> Cc: [email-masked]
> >  > products work, the issue and the solution is much more simple
than
> the
> >  > construction engine". Depending upon whether key rollover has
been
> or
> >  > 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
> >  > I fully agree that this information can not be stored in an AIA.
A
> new
> >  > Preferably this would be a PKCS#7 (or CMS) Certs only message
that
> may

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 21 Sep 2006 07:22:29 -0800

I agree with Stephen.  An individual I-D expressing a crisp problem
statement would be a useful point of focus.

Mike

-----Original Message-----
> From: Stephen Farrell
> Sent: Tuesday, September 19, 2006 10:39 AM
> I'm not sure myself. But I would like to see an
> individual I-D before the WG adopted a work item.