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

From: Sharon Boeyen <[email-masked]>
Date: Thu, 21 Sep 2006 10:19:38 -0400

I still don't see the need to include certificates at all. I don't buy the
network connectivity argument as that would have prevented the path to the
cert from being established too. Also in establishing the certificate path
you may have already downloaded the cert you need anyway. I think if
anything new is added to a CRL, a pointer is a much better solution and
would not cause problems that inclusion of a cert or bag of certs would.

Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 11:18 PM
To: Stephen Farrell; Sharon Boeyen
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

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
Windows Security, Standards

> -----Original Message-----
> 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]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> 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:
> > 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:owner-ietf-
> [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: "Stefan Santesson" <[email-masked]>
Date: Thu, 21 Sep 2006 15:43:29 +0100

Sharon,

We are facing real practical problems that benefit from this type of
solution. Have you read the cases described by Ryan Hurst in this
thread?

> and would not cause problems that inclusion of a cert or bag of certs
would

Can you elaborate the problems. How much extra downloading time would we
add on a CRL that has an extra certificate?

If my calculations are accurate, a certificate would add < 0.2 sec
downloading time in a 56k dialup connection and magnitudes less on a DSL
or LAN connection.

This is most likely much less it takes to initiate a new connection to a
new destination to retrieve the same certificate from a secondary
location.

Both alternatives would still be possible, linking through AIA or
inclusion using a new extension. Why do feel that linking through AIA is
always better?

Stefan Santesson

Senior Program Manager

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 21 september 2006 16:20
To: Stefan Santesson; Stephen Farrell; Sharon Boeyen
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

I still don't see the need to include certificates at all. I don't buy
the network connectivity argument as that would have prevented the path
to the cert from being established too. Also in establishing the
certificate path you may have already downloaded the cert you need
anyway. I think if anything new is added to a CRL, a pointer is a much
better solution and would not cause problems that inclusion of a cert or
bag of certs would.

Cheers, 
Sharon 

-----Original Message----- 
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 11:18 PM 
To: Stephen Farrell; Sharon Boeyen 
Cc: [email-masked] 
Subject: RE: Certs in CRLs - New standards task? 

Sharon, 

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.

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 

always 
schemes 

ignore 

extra 
we 
than 

been 

! 
1 
etc 
CRL 
initially 
A 

and 
make 

AIA 

that