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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Sep 2006 07:08:44 -0700

I would prefer a bag as well, DIME would be ideal but I guess this group would want something ASN.1

Provided BER encoding is allowed I don't see a problem.

Another area where the same problem comes up is when using logotype, it would be nice to be able to deliver the certificate and the logo in one bag. Currently I am using MIME for this.

I would tend to see this as an HTTP extension rather than a PKIX extension. We already have MIME archives of HTML documents with interelated parts. This would be fine for small CRLs but for large CRLs you really do need binary encoding not base 64.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, September 13, 2006 5:46 PM
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: Certs in CRLs - New standards task?
> 
> 
> 
> 
> Stefan Santesson wrote:
> > 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: "Stefan Santesson" <[email-masked]>
Date: Thu, 14 Sep 2006 18:29:48 +0100

I'm open to all solutions that in an effective and practical way solves
the issue.

The reason I primary suggested a non-critical CRL extension was to not
disturb how legacy clients are configured to fetch CRL's and the format
they expect them to arrive.

RFC 3280bis states.

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP scheme is specified, the
   URI MUST point to a CRL file.  The CRL file MUST contain a single DER
   encoded CRL as specified in [RFC 2585].

As such I feel uncertain of the impacts on legacy implementations if a
bag of CRL+Certs is returned. But if this can be done in a smooth way
without causing problems, then I'm all ear.

A non critical CRL extension with a certificate path would simply be
ignored by legacy clients and would not cause any backwards
compatibility problems. Thus it seems like an easier path to me.

I don't believe the CA need to issue one CRL with certs and one without,
as David Kemp suggest. One CRL with a non-critical extension with certs
would work for all. And this would not be included in the common CRLs of
today. It would only be a case for indirect CRLs and possibly when a
rekeyed CA take over revocation of certs issued under an older key.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: den 14 september 2006 07:09
> To: Stephen Farrell; Stefan Santesson
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> Another area where the same problem comes up is when using logotype,
it
> would be nice to be able to deliver the certificate and the logo in
one
> bag. Currently I am using MIME for this.
> 
> 
> I would tend to see this as an HTTP extension rather than a PKIX
> extension. We already have MIME archives of HTML documents with
> interelated parts. This would be fine for small CRLs but for large
CRLs
> you really do need binary encoding not base 64.
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 14 Sep 2006 13:38:12 -0700

I have chatted a bit with Stefan off-line about this, I have some
concerns with embedding certificate chains into CRLs (although I
appreciate the allure of such a approach, especially in catch 22
scenarios where net connectivity isn't there yet).

My largest concern is related to object size, recently I joined the
Networking Team here at Microsoft and have been reviewing some of our
PKI related problems; one of the most significant ends up being
performance of PKI based protocols on high latency links (India to the
US for example).

A great example of this class of problem can be seen in EAP, EAP can be
thought of as  kind of like PAM for layer 2 systems; it is used as the
basis of pre-IP authentication scenarios (think 802.1x); EAP itself does
not provide security services but instead relies on the authentication
protocol (method) being used within EAP to provide these services. Many
EAP methods use TLS as the basis of the security properties they offer
(EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these protocols all suffer
significant performance problems with long chains since EAP doesn't
provide real support for fragmentation.

In the case of the certificate chain related problems in PEAP a 32k
server chain results in about 20 roundtrips, if you think about that in
the context of a roaming wireless user that might experience 1% or more
packet loss this is a big deal.

Although no formal solutions exist here today, we can deal with at the
authentication protocol layer by implementing models that allow for a
client to indicate he doesn't need the protocol to provide it all of the
supplemental evidence (crls, ocsp, intermediates); once you embed this
data into the object all of the time you remove this capability as it
becomes a all or nothing proposition.

With that in mind I prefer models where the client has a choice of which
format of the crl to get (the skinny one [never thought I would call any
crl skinny], or the one with my build :p).

Have you considered the idea of introducing a new access method to the
AIA that would point to a P7c that possibly contained the CRL, its
issuers and maybe the certificates issuers?

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, September 14, 2006 10:30 AM
To: Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]
Subject: RE: Certs in CRLs - New standards task?

RFC 3280bis states.

Stefan Santesson
Senior Program Manager

it
one
CRLs

---

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

From RFC 3280bis

   The authority information access extension indicates how to access
   information and services for the issuer of the certificate in which
   the extension appears.  Information and services may include on-line
   validation services and CA policy data.  (The location of CRLs is not
   specified in this extension; that information is provided by the
   cRLDistributionPoints extension.)

I don't like to change the way clients retrieve CRLs.

Stefan Santesson
Senior Program Manager

> From: Ryan Hurst
> Sent: den 14 september 2006 13:38
> To: Stefan Santesson; Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]; Bernard Aboba
> basis of pre-IP authentication scenarios (think 802.1x); EAP itself
> does not provide security services but instead relies on the
> authentication protocol (method) being used within EAP to provide
these
> services. Many EAP methods use TLS as the basis of the security
> properties they offer (EAP-FAST, EAP-TTLS, EAP-TLS, PEAP, etc.); these
> protocols all suffer significant performance problems with long chains
> since EAP doesn't provide real support for fragmentation.
> 
> client to indicate he doesn't need the protocol to provide it all of
> the supplemental evidence (crls, ocsp, intermediates); once you embed
> this data into the object all of the time you remove this capability
as
> it becomes a all or nothing proposition.
> 
> With that in mind I prefer models where the client has a choice of
> which format of the crl to get (the skinny one [never thought I would
> call any crl skinny], or the one with my build :p).
> 
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson

---

From: Ryan Hurst <[email-masked]>
Date: Thu, 14 Sep 2006 14:16:47 -0700

I understand - I am not sure you understand my scenario, lets sync
off-line.

-----Original Message-----
From: Stefan Santesson 
Sent: Thursday, September 14, 2006 2:14 PM
To: Ryan Hurst; Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]; Bernard Aboba
Subject: RE: Certs in CRLs - New standards task?

From RFC 3280bis

Stefan Santesson
Senior Program Manager

these
as

---

From: Ryan Hurst <[email-masked]>
Date: Sun, 17 Sep 2006 08:34:45 -0700

Well Stefan and I spoke off-line; I now that I better understand the
scope of the proposal (recommendations for indirect CRLs for CA issuing
CAs only) I am OK.

:)

Ryan

-----Original Message-----
From: Stefan Santesson 
Sent: Thursday, September 14, 2006 2:14 PM
To: Ryan Hurst; Hallam-Baker, Phillip; Stephen Farrell
Cc: [email-masked]; Bernard Aboba
Subject: RE: Certs in CRLs - New standards task?

From RFC 3280bis

Stefan Santesson
Senior Program Manager

these
as

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 18 Sep 2006 15:21:31 +0200

> issuers and maybe the certificates issuers?
I vote for p7c. Most CAs already include an option to distribute CRL 
this way.

After reading  RFC 2585, I think it misses something  by not saying a 
word about the popular option of distributing crl and certificates 
inside pkcs#7/CMS bags.

When RFC 3280bis says that URIs inside a DistributionPointName must 
point to a single DER encoded CRL (no "PEM", no pkcs#7 bag), is it just  
making explicit a rule that was already required for proper 
interoperability ?

---

From: Christine Karman <[email-masked]>
Date: Mon, 18 Sep 2006 16:26:43 +0200

Hi,
I'm more of a lurker here, and I don't know if my question is 
appropriate in this forum.

We see crl's that are huge, like a DOD crl of 20MB. Assuming that you 
want to refresh the crl every couple of hours, this can put a strain 
on an application or a machine. Imagine using wifi at Starbucks, and 
your mail comes with 40MB of crls. Or an appliance that decrypts 15 
msgs/sec and then has to stop for downloading 20MB.
We're optimizing our code, but wouldn't it be better to limit the 
size of a crl and rather use multiple crl distribution points?

dagdag
Christine
-- 
Izecom BV
Secure e-mail and digital signatures
www.izecom.com

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Sep 2006 11:45:48 -0400

I support the idea of carrying a bag 'o certs.  However, I am not use 
what value is added by carrying a p7c.  It seems to be a heavy weight 
way to say SEQUENCE OF Certificate.

What am I missing?

Russ

At 09:21 AM 9/18/2006, Jean-Marc Desperrier wrote:

>I vote for p7c. Most CAs already include an option to distribute CRL this way.
>
>After reading  RFC 2585, I think it misses something  by not saying 
>a word about the popular option of distributing crl and certificates 
>inside pkcs#7/CMS bags.
>
>making explicit a rule that was already required for proper interoperability ?
>

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 18 Sep 2006 16:46:16 +0100

The problems with introducing a CRL bundled with certificates in a p7c
file linked through AIA is: 

1) It violates the defined usage of AIA.
2) It confuses the picture for implementers whether they should use CDP
or use AIA for CRL retrieval.
3) It confuses the CDP distribution point matching between IDP and CDP.

Therefore, I don't like it.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Jean-Marc Desperrier
> Sent: den 18 september 2006 06:22
> To: [email-masked]

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Mon, 18 Sep 2006 09:42:33 -0700

The 5th edition of X.509 has added the ability to specify ranges of certificate serial numbers.

Of course, if the SHA-1 problem is handled by appending random values onto the serial number, this won't be a useful extension.

   hoyt

At 16:26 +0200 9/18/06, Christine Karman wrote:
>Hi,
>I'm more of a lurker here, and I don't know if my question is appropriate in this forum.
>
>We see crl's that are huge, like a DOD crl of 20MB. Assuming that you want to refresh the crl every couple of hours, this can put a strain on an application or a machine. Imagine using wifi at Starbucks, and your mail comes with 40MB of crls. Or an appliance that decrypts 15 msgs/sec and then has to stop for downloading 20MB.
>We're optimizing our code, but wouldn't it be better to limit the size of a crl and rather use multiple crl distribution points?
>
>dagdag
>Christine
>--
>Izecom BV
>Attachment converted: Macintosh HD:smime 122.p7s (    /    ) (001E7ABB)

---

From: "Kemp David P." <[email-masked]>
Date: Mon, 18 Sep 2006 13:13:20 -0400

Christine,

Yes, the DoD CRLs are the ridiculous result of designing a
system based on the limitations of then-current products
(the inability of some applications to understand CRLDP)
rather than designing a correct system and expecting
commercial products to evolve.  Several years later,
browsers have gone through multiple generations of
improvement, while DoD PKI is still stuck with dinosaur
CRLs (in both senses: obsolete and huge).

The DoD PKI's (admittedly clever) workaround was to create
OCSP responses that resemble partitioned CRLs - pre-generated
rather than signed on demand, and partitioned into blocks
of 20 or so certificates to avoid generating individual
OCSP responses for every certificate.  Clever though
that solution might be, it would still be more efficient
to just generate small-partitioned CRLs (20-100 certs)
in the first place, because OCSP message overhead is
higher than that of a bare CRL.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Christine Karman
Sent: Monday, September 18, 2006 10:27 AM
To: [email-masked]
Subject: large crl's

Hi,

dagdag
Christine

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2006 12:37:02 -0400

At 4:26 PM +0200 9/18/06, Christine Karman wrote:
>We see crl's that are huge, like a DOD crl of 20MB. Assuming that 
>you want to refresh the crl every couple of hours, this can put a 
>strain on an application or a machine. Imagine using wifi at 
>Starbucks, and your mail comes with 40MB of crls. Or an appliance 
>that decrypts 15 msgs/sec and then has to stop for downloading 20MB.
Christine,

One cannot limit the size of a CRL, as that implies either not 
putting on new entries, or dropping old entries for certs that have 
not yet expired.  Using multiple CRLDPs is a way of reducing CRL 
size, but if one needs to check for all issued, not expired certs, 
this still does not solve the problem of download a lot of data.

There are other options:

	- use OCSP queries to get revocation status data for certs of 
interest, vs. all certs

	- don't publish a CRL every two hours! or don't fetch one 
every two hours (the gating item in revocation status notification is 
usually the time it takes o decide to revoke a cert, not the time it 
takes to propagate a CRL. I don't think it makes sense for most 
applications to publish a CRL more often that daily.)

Steve

---

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 18 Sep 2006 18:26:41 +0100

I think you are right.

We initially thought of a p7c since it is how we normally store bag of
certs, but in this case that overhead is probably not doing us any good.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 18 september 2006 08:46
> To: Jean-Marc Desperrier; [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Sep 2006 12:30:37 -0700

At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:
>Of course, if the SHA-1 problem is handled by appending random 
>values onto the serial number, this won't be a useful extension.

Is that true? If your starting serial numbers are a fixed number of 
octets (such as four), and you append a fixed number of octets of 
randomness, you can still specify ranges, can't you?

--Paul Hoffman, Director
--VPN Consortium

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Mon, 18 Sep 2006 13:25:05 -0700

You're correct. If the serial number is fixed size and the fixed length most significant part is composed of an increasing value (or decreasing if you decide to be somewhat outré), then the fixed length least significant part can be as random as you please.

   hoyt

At 12:30 -0700 9/18/06, Paul Hoffman wrote:
>Is that true? If your starting serial numbers are a fixed number of octets (such as four), and you append a fixed number of octets of randomness, you can still specify ranges, can't you?
>
>--Paul Hoffman, Director
>--VPN Consortium

---

From: "Kemp David P." <[email-masked]>
Date: Mon, 18 Sep 2006 17:39:05 -0400

Of course, if your subscribers aren't so courteous as to
lose their keys, change jobs, or otherwise request revocation
in the order they received their certificates, ranges might
not be that useful anyway :-).

(I realize that there are circumstances where issuing
and revoking a block of certificates is useful.  But those
circumstances are limited.)

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Monday, September 18, 2006 3:31 PM
To: Hoyt L Kesterson II; [email-masked]
Subject: Re: large crl's

--Paul Hoffman, Director
--VPN Consortium

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Mon, 18 Sep 2006 16:18:08 -0700

This was one of two CRL enhancements that were originally
submitted by Japan. They found that company reorganizations
often required a reissuing of certificates - the higher the level of
reorg, the more certificates that had to be revoked and
reissued.

This led them to two conclusions.

1) bulk creations were sometimes followed by bulk
revocations; these typically were within a range of serial numbers or
within a subtree.

2) the revocations were something that could be planned
ahead of time

Even though it didn't happen that often, when it did happen, a
range or subtree descriptor could replace a long list of serial
numbers. Thus the revokedGroups extension (8.5.2.11) was
created.

Revocations because of reorganizations would normally be planned
well in advance of the date of the revocations. The group thought it
would be useful to have a trusted way to signal that one or more
individually listed certificates, a range of certificates, or those
certificates whose subject/holder name was in a specified subtree
would be revoked at future date and time. Thus came the obscurely
named toBeRevoked extension (8.5.2.10)

Granted, an organizationally independent naming scheme would
avoid such problems but sometimes reorgs happen and names are
affected. These extensions could help.

hoyt

At 17:39 -0400 9/18/06, Kemp David P. wrote:

Of course, if your subscribers aren't so
courteous as to

Dave

-----Original Message-----

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

Subject: Re: large crl's

At 9:42 AM -0700 9/18/06, Hoyt L Kesterson II wrote:

>The 5th edition of X.509 has added the ability to specify ranges
of

>certificate serial numbers.

>values onto the serial number, this won't be a useful
extension.

Is that true? If your starting serial numbers are a fixed number
of

--Paul Hoffman, Director

--VPN Consortium

---

From: Christine Karman <[email-masked]>
Date: Tue, 19 Sep 2006 11:04:30 +0200

>system based on the limitations of then-current products

It would be nice if CA's would use OCSP rather than crl's.

>Several years later,
>improvement,

We don't do brosers, we do email. Think of ten messages per second 
being encrypted or decrypted, with new certificates and possibly new 
crl's coming in all the time. Of course, the number of crl's is 
limited, and we probably have to accept that we don't download larget 
crl's more often than every couplf of hours, or even a day. That does 
mean that if a certificate gets revoked, a hacker will have 24 hours 
to use this compromised certificate.

Another difference between authentication in a browser and email is 
the following. A company archives old email. They have to be able to 
verify validity of digital signatures on incoming email, even for 
certificates that have expired long ago. The DOD will have to have 
that 20Mb crl available forever, unless they switch to online verification.

dagdag
Christine

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 19 Sep 2006 07:33:13 -0400

Christine,

AWA:  Experience - at least within some circles - has shown that in the
general case the time between when the certificate should be revoked (e.g.,
when the key is actually compromised) and the incident is reported to the CA
is MUCH greater than the time to distribute the revocation information,
whether the distribution is by CRL or OCSP. That is, users don't discover
that their keys have been compromised until some external event occurs -
they realized that their token is missing; or they're notified of some
transaction in which they didn't participate; etc.  Once a compromise is
reported, there is generally some period of investigation to determine if
the report is genuine (otherwise you're subject to neat denial of service
attacks in which I just report each of your keys as compromised), and this
adds to the total time it takes to push the revocation out.  This tends in
many cases to be much greater than the 24 hours (or less) it takes to push
the revocation information out to all users in the system. (Yes, there are
exceptions and that's why some organizations really want OCSP, but of course
it then has its own issues.)

AWA:  First, the browser transactions are often archived, just like e-mail.
Second, even with on-line verification, some part of the system has to store
forever the certificate validity information if you want to do retroactive
validation. You can store it centrally, or with the messages, or whatever.
There are "good engineering solutions" to the problem and "bad engineering
solutions" to the problem, but it tends not to matter over time which you
do, you still have to store all the information for later retrieval.

            Al Arsenault

---

From: Joel Kazin <[email-masked]>
Date: Tue, 19 Sep 2006 08:42:22 -0400

The issue is not limited to revoking compromised certificates. All the 
PKIs that I have designed revoke the respective end entity certificates 
when the employee or contractor leaves the organization. While such 
certificates are normally revoked once a day through an interface to the 
directory of record, the CP states that such revocation may be made more 
frequently and the CRLs can be published several times a day. Also, 
there are situations, for example employee defalcation, where you would 
want to revoke a certificate immediately. In practice, the number of 
routine revocations greatly exceeds the number due to compromise or 
immediate need.

Al Arsenault wrote:

> AWA: Experience – at least within some circles - has shown that in the 
> general case the time between when the certificate should be revoked 
> (e.g., when the key is actually compromised) and the incident is 
> reported to the CA is MUCH greater than the time to distribute the 
> revocation information, whether the distribution is by CRL or OCSP. 
> That is, users don’t discover that their keys have been compromised 
> until some external event occurs – they realized that their token is 
> missing; or they’re notified of some transaction in which they didn’t 
> participate; etc. Once a compromise is reported, there is generally 
> some period of investigation to determine if the report is genuine 
> (otherwise you’re subject to neat denial of service attacks in which I 
> just report each of your keys as compromised), and this adds to the 
> total time it takes to push the revocation out. This tends in many 
> cases to be much greater than the 24 hours (or less) it takes to push 
> the revocation information out to all users in the system. (Yes, there 
> are exceptions and that’s why some organizations really want OCSP, but 
> of course it then has its own issues.)
>
> AWA: First, the browser transactions are often archived, just like 
> e-mail. Second, even with on-line verification, some part of the 
> system has to store forever the certificate validity information if 
> you want to do retroactive validation. You can store it centrally, or 
> with the messages, or whatever. There are “good engineering solutions” 
> to the problem and “bad engineering solutions” to the problem, but it 
> tends not to matter over time which you do, you still have to store 
> all the information for later retrieval.
>
> Al Arsenault
>

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 19 Sep 2006 10:13:04 -0400

Joel,

True, but I was responding to Christine's original comment that 

"That does mean that if a certificate gets revoked, a hacker will have 24
hours to use this compromised certificate."

Anticipated revocations, such as an employee leaving an organization, should
not fall into this category. Every time I've left an organization, there's a
standard process for revoking my certificate, invalidating my badge so it
doesn't open the doors any more, returning physical keys, credit cards, etc.
This should not cause a significant burden on the PKI if done properly.

(An example - when I left the US Government, the organization always
processed outgoing employees on Fridays.  You went to a central office at 9
am on Friday, and they invalidated the badge, revoked the cert, etc. etc.
then.  If you didn't want to work up until Friday, you didn't have to - you
could take paid or unpaid vacation for as much of the rest of the week as
you wanted, but you checked out on Friday.  This made it easier for
revocation purposes.  This did not apply to people being fired, obviously.)

With the emergency revocation - I'm assuming you mean "defalcation" in the
sense of "embezzlement" - yes, you want to revoke immediately, but by your
own assumption the employee has already been misusing the certificate for
some period of time, most likely longer than a few hours - so my original
point still holds.

			Al Arsenault

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joel Kazin
Sent: Tuesday, September 19, 2006 8:42 AM
To: Al Arsenault
Cc: 'Christine Karman'; 'Kemp David P.'; [email-masked]
Subject: Re: large crl's

Al Arsenault wrote:

> That is, users don't discover that their keys have been compromised 
> until some external event occurs - they realized that their token is 
> missing; or they're notified of some transaction in which they didn't 
> (otherwise you're subject to neat denial of service attacks in which I 
> are exceptions and that's why some organizations really want OCSP, but 
> with the messages, or whatever. There are "good engineering solutions" 
> to the problem and "bad engineering solutions" to the problem, but it

---

From: "Kemp David P." <[email-masked]>
Date: Tue, 19 Sep 2006 10:21:39 -0400

Al Arsenault already discussed good and bad engineering solutions,
but the following suggests some elaboration:

> [ck] Another difference between authentication in a browser
> and email is the following. A company archives old email.
> They have to be able to verify validity of digital signatures
> on incoming email, even for certificates that have expired
> long ago. The DOD will have to have that 20Mb crl available
> forever, unless they switch to online verification.

What does "online verification" mean: a mechanism to
query for certificate status and receive an answer?  If so,
then what is the difference between receiving the answer in
the form of a signed OCSP response or a signed partitioned CRL?

One difference is size.  For any given number of certificates,
an OCSP response is significantly *larger* than a CRL!  An
OCSP message is about 350 bytes body + 79/unrevoked
cert + 101/revoked cert.  A CRL, in contrast, is about
200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number
size, signature size, use of extensions, etc).  

Assuming 1% of certificates are revoked, the size of a
CRL and an OCSP response for a given number of certificates
per CRL partition or OCSP query is:

Certs/   1% revoked
query    CRL    OCSP
   1     200     429
   2     201     508
   5     202     746
  10     203   1,142
  20     206   1,934
  50     215   4,311
 100     230   8,272
 200     260  16,194
 500     350  39,960
1000     500  79,570

If a 1% revocation rate doesn't reflect your subscriber
base, then assume 40% of certificates are revoked, yielding
the following CRL and OCSP sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query
on 1000 certs?  It means that if you set some threshold
on the acceptable size for a certificate status message,
a CRL can represent the status of many more certificates
than an OCSP response.  If 500 bytes is your limit, that
would be an OCSP response for 2 certs, or a partitioned
CRL covering 20 certs.  If 2K bytes is your limit, that
would accommodate an OCSP response for 20 certs, or a
CRL covering a 150-cert partition.

Another way of looking at it would be to assume that
a company needs to store revocation status for email
messages of its 10,000 employees.  If it stored 10
partitioned CRLs, that would require 122 KB.  If instead
it stored 10,000 OCSP responses, that would require
4,380 KB for the same set of employees.

The point of the above is that it is incorrect to assume
that "online verification" means only "OCSP", and even more
incorrect to assume that because one organization has
done a horrible job of engineering its CRLs, the
fault lies with the CRLs themselves.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 19 Sep 2006 11:20:58 -0700

I was not personally suggesting the CRL carry a P7C but instead that a
certificate provide a pointer to a p7c that contains both the CRL and
the certificates that are necessary to validate it this way a
implementation that supported this model could choose this form of CRL
vs the traditional form.

However after speaking with Stefan I think we both better understand
each other's scenarios and I now agree with Stefan, supporting a mode
where a CRL contains sufficient information to kick of validation and
then discovery for indirect CRL cases without having to go on the wire
makes sense.

By scoping the inclusion of this proposed extension to indirect crls
associated with CAs you mitigate the performance and file size problems
that I was concerned with while still enabling solving the problem
Stefan calls out.

Ryan
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Monday, September 18, 2006 8:46 AM
To: Jean-Marc Desperrier; [email-masked]
Subject: Re: Certs in CRLs - New standards task?

What am I missing?

Russ

this way.
interoperability ?

---

From: "Dave Engberg" <[email-masked]>
Date: Tue, 19 Sep 2006 17:50:10 -0400

This is comparing a theoretical against an actual.

If the US DoD were using the CA that supports automated CRL partitioning,
then each CRL would represent the status of 750 certs.  With the DoD's 20%
rate of revocation, the average CRL partition would have 150 entries, or
around 3.7kB.  This is twice as large as the actual OCSP responses returned
by the DoD today, and the upper bound on a CRL partition size is
significantly larger.

It's important to note that any CRL partitioning is fixed for the entire
lifetime of the certs ... you can't change your tuning later to improve
bandwidth to the client or (inversely) the aggregate size and number of
segments to replicate.  An OCSP deployment can be tuned independently long
after cert issuance based on the operational usage characteristics.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kemp David P.
Sent: Tuesday, September 19, 2006 10:22 AM
To: Christine Karman; [email-masked]
Subject: RE: large crl's

...

One difference is size.  For any given number of certificates, an OCSP
response is significantly *larger* than a CRL!  An OCSP message is about 350
bytes body + 79/unrevoked cert + 101/revoked cert.  A CRL, in contrast, is
about 200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number size, signature size, use
of extensions, etc).  

...

If a 1% revocation rate doesn't reflect your subscriber base, then assume
40% of certificates are revoked, yielding the following CRL and OCSP sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query on 1000 certs?  It
means that if you set some threshold on the acceptable size for a
certificate status message, a CRL can represent the status of many more
certificates than an OCSP response.  If 500 bytes is your limit, that would
be an OCSP response for 2 certs, or a partitioned CRL covering 20 certs.  If
2K bytes is your limit, that would accommodate an OCSP response for 20
certs, or a CRL covering a 150-cert partition.

Another way of looking at it would be to assume that a company needs to
store revocation status for email messages of its 10,000 employees.  If it
stored 10 partitioned CRLs, that would require 122 KB.  If instead it stored
10,000 OCSP responses, that would require 4,380 KB for the same set of
employees.

The point of the above is that it is incorrect to assume that "online
verification" means only "OCSP", and even more incorrect to assume that
because one organization has done a horrible job of engineering its CRLs,
the fault lies with the CRLs themselves.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Sep 2006 20:56:02 -0400

>that 20Mb crl available forever, unless they switch to online 

There is no requirement for a CA to maintain entries on a CRL after 
the certs in question have expired.  Your model re CRL management is 
inconsistent with RFC 3280 requirements.

Steve

---

From: Joel Kazin <[email-masked]>
Date: Wed, 20 Sep 2006 09:42:35 -0400

As Steven writes, RFC 3280 clearly places no obligation for CRLs to 
include information on revoked certificates issued after their 
respective notAfter dates.  However, there is often a obligation in the 
CP or a need to prove that a CRL issued in the past indicated that the 
certificate was revoked..

---

From: "Kemp David P." <[email-masked]>
Date: Wed, 20 Sep 2006 09:50:56 -0400

Hi Dave,

Good to discuss this with you again.

1) I find it difficult to believe that an ECP to change a CA
product's fixed partition size of 750 to a configurable
partition size would be that expensive.  And even with
the fixed size, 3.7KB is not an unreasonable status
size when compared to 20MB CRLs or the average size of
an email message or web page.

Also, although an individual 750 cert CRL is twice the size of an
individual 20 cert OCSP, the aggregate of OCSP for 10 million
subscribers is nearly 20 times the aggregate of CRLs
(half a million OCSPs vs. 13 thousand CRLs, or 925MB vs. 50MB).

2) I have never understood the point you make about tuning.
With a fixed partition size of 750 certs, even if some event
caused 100% of them to be revoked immediately after issuance,
that would result in a CRL of 22.7KB (modulo assumptions)
being issued for the life of the certs (3 years).  22.7KB isn't
a killer, and one wouldn't expect new usage of a certificate
3 years after it was revoked.  So those 22.7KB CRLs would be
fetched for a few days until the certs were flushed out of
the system, with a small usage tail coming from people
verifying archived signed data.  That just isn't a problem
that needs solving.  Optimization per subscriber community
is nice (device certs might be revoked less frequently than
people certs, so device CRLs would cover more certs per
partition), but additional dynamic optimization over the
lifetime of a cert gets into diminishing returns.

Another advantage of partitioned CRLs over OCSP is that they
can be treated just like any other web document - cached by
proxies that everyone has already deployed to support normal
web traffic.  It's great that the DoD OCSP service uses Akamai
technology, but custom provisioning to support OCSP costs more
than off-the-shelf provisioning already in place for the web.

Dave

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2006 5:50 PM
To: Kemp David P.; Christine Karman; [email-masked]
Subject: RE: large crl's

If the US DoD were using the CA that supports automated CRL
partitioning,
then each CRL would represent the status of 750 certs.  With the DoD's
20%
rate of revocation, the average CRL partition would have 150 entries, or
around 3.7kB.  This is twice as large as the actual OCSP responses
returned
by the DoD today, and the upper bound on a CRL partition size is
significantly larger.

segments to replicate.  An OCSP deployment can be tuned independently
long

-----Original Message-----
On

...

One difference is size.  For any given number of certificates, an OCSP
response is significantly *larger* than a CRL!  An OCSP message is about
350
bytes body + 79/unrevoked cert + 101/revoked cert.  A CRL, in contrast,
is
about 200 bytes body + 0/unrevoked cert + 30/revoked cert.
(both modulo assumptions on DN size, serial number size, signature size,
use
of extensions, etc).  

...

If a 1% revocation rate doesn't reflect your subscriber base, then
assume
40% of certificates are revoked, yielding the following CRL and OCSP
sizes:

Certs/   40% revoked
query    CRL    OCSP
   1     212     438
   2     224     526
   5     260     789
  10     320   1,228
  20     440   2,106
  50     800   4,740
 100   1,400   9,130
 200   2,600  17,910
 500   6,200  44,250
1000  12,200  88,150

What does this mean, since nobody does an OCSP query on 1000 certs?  It
means that if you set some threshold on the acceptable size for a
certificate status message, a CRL can represent the status of many more
certificates than an OCSP response.  If 500 bytes is your limit, that
would
be an OCSP response for 2 certs, or a partitioned CRL covering 20 certs.
If
2K bytes is your limit, that would accommodate an OCSP response for 20
certs, or a CRL covering a 150-cert partition.

Another way of looking at it would be to assume that a company needs to
store revocation status for email messages of its 10,000 employees.  If
it
stored 10 partitioned CRLs, that would require 122 KB.  If instead it
stored
10,000 OCSP responses, that would require 4,380 KB for the same set of
employees.

The point of the above is that it is incorrect to assume that "online
verification" means only "OCSP", and even more incorrect to assume that
because one organization has done a horrible job of engineering its
CRLs,
the fault lies with the CRLs themselves.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Sep 2006 18:02:24 -0400

At 9:42 AM -0400 9/20/06, Joel Kazin wrote:
>respective notAfter dates.  However, there is often a obligation in 
>the CP or a need to prove that a CRL issued in the past indicated 
>that the certificate was revoked..
>

If the CP or CPS imposes such an obligation, then it becomes the 
responsibility of the CA to make older CRLs available. But the 
default, as per X.509 and RFC 3280, is NOT to mandate such archiving. 
This is reasonable under a "receipt model" which calls for the 
parties to a signed transaction to obtain and retain data like the 
certs and CRLs relevant to the transaction.

Steve

---

From: Christine Karman <[email-masked]>
Date: Mon, 25 Sep 2006 23:59:05 +0200

At 12:02 AM 9/21/2006, Stephen Kent wrote:

>default, as per X.509 and RFC 3280, is NOT to mandate such 
>archiving. This is reasonable under a "receipt model" which calls 
>for the parties to a signed transaction to obtain and retain data 
>like the certs and CRLs relevant to the transaction.

If a "transaction" is an email message, that would mean that you have 
to keep a crl for every message, or you have to compare crl's and 
keep old one's as soon as certs expire. This decreases the 
performance of a machine, so client needs to buy a bigger one. 
Clients generally don't want to pay for that. However, they do expect 
their system to know if a cert was valid when the message was sent. 
Maybe we should just use ocsp.

dagdag
Christine

-- 
Izemail beveiligt uw email met encryptie en handtekening
www.izecom.com

---

From: "Al Arsenault" <[email-masked]>
Date: Tue, 26 Sep 2006 07:49:42 -0400

Christine,

If a "transaction" is an email message, that would mean that you have 
to keep a crl for every message, 

AWA: Dave Kemp and I have both noted numerous times that there are solutions
involving "good engineering" and solutions involving "bad engineering" with
both CRLs and OCSP. That, to me, would be an example of very "bad
engineering". 

or you have to compare crl's and 

AWA:  First, why does the "proof" (message and archived CRL) have to be kept
on the client machine?  Given that the primary use for this is long-term
archiving, that strikes me once again as sub-optimal engineering. Use a
central server/collection point for long-term archiving purposes, and let
the clients query on those occasions when validity must be determined long
after the certificate has expired.  No need for bigger client machines.

AWA:  Certainly, you could "just use OCSP", and for some situations it might
be better than well-engineered CRLS (and for other situations OCSP might be
worse).  But you're still going to have to provide a full solution to the
problem.  If you want everything done on the client machine, you have to
save the OCSP responses with the messages (and, of course, you're going to
have to store or have access to some way of proving that the OCSP response
was valid).  Or you're providing everything on a central OCSP server which
can generate the retro-active validity messages, in which case this reduces
to being equivalent to the CRL solution.

AWA: As Santosh has already pointed out, a lot of this is being worked in
the LTANS group.

Thanks

			Al Arsenault

---

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Sep 2006 09:52:20 -0400

At 11:59 PM +0200 9/25/06, Christine Karman wrote:
>If a "transaction" is an email message, that would mean that you 
>have to keep a crl for every message, or you have to compare crl's 
>and keep old one's as soon as certs expire. This decreases the 
>Clients generally don't want to pay for that. However, they do 
>expect their system to know if a cert was valid when the message was 
>sent. Maybe we should just use ocsp.
>
>dagdag
>Christine
>
Christine,

One would not need to keep a copy of a CRL for each e-mail message, 
unless the time between each message is shorter than the issuance 
frequency of the relevant CRLs. If a CRL is issued on a daily basis, 
then all transactions during a day, with correspondents using certs 
issued by the same CA, need to reference just the one CRL issued by 
the CA in question for the interval in question.  And, of course, I 
could note that storage continues to get cheaper over time.

OCSP is fine, if by that you mean retaining an OCSP response in lieu 
of a CRL for each relevant CA for each time period.

Note that SCVP include an explicit facility to support a query of the 
form "Was this cert valid at time X," where X is in the past. Thus an 
SCVP server can perform the desired function as well.

Steve