Subject: Certs in CRLs - New standards task?

From: Stefan Santesson <[email-masked]>
Date: Wed, 13 Sep 2006 17:07:41 +0100

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: "Dave Engberg" <[email-masked]>
Date: Wed, 13 Sep 2006 15:23:40 -0400

This sounds like a great idea.  Real-world availability and reliability of
directories and servers is a gigantic issue for complex (e.g.
cross-certified) PKI environments.  This solution removes one extra lookup
from the mix with a negligible size overhead on the CRL.

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, September 13, 2006 12:08 PM
To: [email-masked]
Subject: Certs in CRLs - New standards task?

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.

 

Stefan Santesson

Senior Program Manager

---

From: Tilo Kienitz <[email-masked]>
Date: Wed, 13 Sep 2006 22:07:47 +0200

Stefan Santesson wrote:
 > [...]

I like this idea. It would make CRL validation as easy as OCSP response
validation where the issuer's certificate is also included.

Kind regards
Tilo Kienitz

-- 
Tilo Kienitz
SecCommerce Informationssysteme GmbH
Obenhauptstr. 5
D - 22335 Hamburg                         http://www.seccommerce.de
Germany

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Sep 2006 16:56:25 -0400

Stefan:

Could this be done as a new accessMethod / accessLocation in the
AIA?

Russ

At 12:07 PM 9/13/2006, Stefan Santesson wrote:

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.

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.

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: "Kemp David P." <[email-masked]>
Date: Wed, 13 Sep 2006 17:21:51 -0400

Stefan,

I'm skeptical that including a certificate path within the security
envelope of a CRL is the best approach.  In many cases (particularly in
ARLs which should normally be empty) this would add considerable
overhead.  And even in CRLs which are 10x the size of the CRL issuer's
cert path, that extra 10% bandwidth penalty is repeated every time a CRL
is fetched, not just every time a new CRL issuer cert is needed.  Since
CRLs are updated much more frequently than certs, binding them together
forces unnecessary bandwidth inefficiencies.

Issue #2 is not real:  because you cannot make this feature mandatory
(i.e. prohibit the use of AIA in CRLs), you cannot write applications
that refuse to execute AIA and thus refuse to participate in DoS
attacks.  Instead, to avoid this issue applications should not fetch a
CRL from certificates that do not trace back to a trust anchor.  If a
trusted certificate has a rogue AIA, there are bigger problems than DoS.

To address Issue #1, it would be preferable to define a bag that
contains both a CRL and the CRL issuer cert path.  That way CRL issuers
would not be forced to generate both cert-extension CRLs and normal
CRLs.  The bag could instead be generated on demand by the CRL
repository or by local proxies.

Dave Kemp

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, September 13, 2006 12:08 PM
To: [email-masked]
Subject: Certs in CRLs - New standards task?

 

Stefan Santesson

Senior Program Manager

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Sep 2006 22:45:52 +0100

> I would like to hear the opinion of this group on this.

Sounds like an interesting idea - would like to see a draft
all right. (Though David Kemp's idea of wrapping the cert and
CRL a bag might also be worth investigating, depending on the
CRL consuming protocols one is considering.)

However, I'd have to wonder whether extending the life of the
PKIX WG by another couple of years would be the right approach.
Would it be better to first consider re-chartering or else
chartering a new WG? (I'm not saying I think either is the
way to go, but PKIX has been on the go for a looong time.)

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Sep 2006 16:35:54 -0700

At 10:45 PM +0100 9/13/06, Stephen Farrell wrote:
>chartering a new WG?

Or just submitting it as an individual submission without a WG behind 
it? Even after this WG closes down, this mailing list will continue 
on. FWIW, there are about 850 people on the mailing list, and most if 
not all will probably stay on after the WG closes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 14 Sep 2006 01:30:15 +0100

Paul,

That was my intention. I just wanted to see the reaction from people on
this list before writing the draft.
To assign it to a WG is a secondary problem.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 13 september 2006 16:36
> To: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 14 Sep 2006 01:55:39 +0100

Not as AIA currently is formed:

   AccessDescription  ::=  SEQUENCE {

           accessMethod          OBJECT IDENTIFIER,

           accessLocation        GeneralName  }

This syntax does not allow encapsulation of any data, just a
name/poiner.

Stefan Santesson

Senior Program Manager

From: Russ Housley [mailto:[email-masked]] 
Sent: den 13 september 2006 13:56
To: Stefan Santesson; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

Stefan:

Could this be done as a new accessMethod / accessLocation in the AIA?

Russ

 

 

 

Stefan Santesson
Senior Program Manager

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Sep 2006 08:10:49 -0400

Obviously correct.  Please excuse the brain bubble.

Russ

At 08:55 PM 9/13/2006, Stefan Santesson wrote:

accessMethod          OBJECT
IDENTIFIER,

accessLocation
GeneralName  }

Stefan Santesson

Senior Program Manager

From: Russ Housley
[
mailto:[email-masked]]

Stefan:

Russ

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.

Stefan Santesson

Senior Program Manager

---

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 14 Sep 2006 18:39:17 +0100

Dave,

I agree that the DoS attack threat is not major so we should not pitch
that as a primary reason for doing this.

Stefan Santesson

Senior Program Manager

From: Kemp David P. [mailto:[email-masked]] 
Sent: den 13 september 2006 14:22
To: Stefan Santesson; [email-masked]
Subject: RE: Certs in CRLs - New standards task?

Stefan,

Dave Kemp

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.

 

Stefan Santesson

Senior Program Manager