Subject: [pkix] Guidelines for Need for CRL/OCSP?

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 3 Feb 2011 10:22:29 -0800

If your certificates are always issued with really short lifetimes (a few hours) it makes no sense to incur the deployment overhead of maintaining CRL/OCSP infrastructure.  OTOH if they have lifetimes of a year or more, it seems foolish not to.

Is there any recommended policy covering this?  Any recommended crossover point that could be referenced in another specification?
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sean Turner <[email-masked]>
Date: Thu, 03 Feb 2011 13:24:35 -0500

Start using OCSP as soon as your CRL might be bigger than an OCSP 
response ;)

spt

On 2/3/11 1:22 PM, Henry B. Hotz wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Pierre Pavlenyi <[email-masked]>
Date: Thu, 3 Feb 2011 14:07:43 -0500

Henry,

There is no "recommended" policy that I am aware of in terms of when you should or should not use CRLs and/or OCSP.

This begs the question: What is(are) your use case(s)?

If your Relying Party (RP) never has to see if the certificate has been revoked, and are happy simply checking the validity and/or perform path validation, then yes, you don't need to incur the overhead of a CRL/OCSP infrastructure.  Note the "never" part of the previous sentence though.  If you don't have CRL and/or OCSP in your certificate, then the RP can never check for certificate revocation; they can only check validity and perform path validation.

If anywhere in your use case your RP needs to see if a Certificate has been revoked, your stuck having to use CRL and/or OCSP.  At which point you have to ask yourself another question:  what kind of response is my RP looking for in terms of making a revocation determination?  This will help you decide if you want CRL and/or OCSP.

Nail down your use case(s), and that will lead you down the right path :-)

-----------------------
Pierre Pavlenyi, P.Eng
Identity Management Architect
[email-masked]

The opinions expressed here are strictly my own, and do not represent those of any other party.

On 2011-02-03, at 1:24 PM, Sean Turner wrote:

> Start using OCSP as soon as your CRL might be bigger than an OCSP response ;)
> 
> spt
>

---

From: Mike Helm <[email-masked]>
Date: Thu, 03 Feb 2011 11:34:12 -0800

Pierre Pavlenyi writes:
> If anywhere in your use case your RP needs to see if a Certificate has =
> been revoked, your stuck having to use CRL and/or OCSP.  At which point =

> Nail down your use case(s), and that will lead you down the right path =
> >> If your certificates are always issued with really short lifetimes (a =

A lot of the use cases, especially those associated with really short
lifetime certificates, are faulty - or circular: the reason the lifetime
is short is to avoid CRLs, or at least make them infeasible.

Two things have shown up in practice:
(1) the short lifetimes are inconvenient, so the the lifetime has inflationary
pressure :^) to get longer & longer
(2) even if the the lifetime is kept short, you never need CRLs - until the one
day when you really, really, wish you had them instead of having to revoke the
CA  and tell all the RPs to stop working (or take the risk) for a few hours/days 
until the garbage certificates time out.

I personally do not think that any authentication mechanism should be used
that lacks a revocation method.  I understand there is a cost associated.

Regards, ==mwh
Michael Helm
ESnet/LBNL

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 3 Feb 2011 13:44:54 -0800

The use case is KX509, which is a protocol for acquiring X.509 client certs using a Kerberos ticket to prove identity to an automated CA.  These certs are only useful for TLS client authentication, and typically are issued with the same (short) expiration time as the original Kerberos ticket.

I've had it pointed out that there is nothing inherent to the protocol which prevents issuing X.509 client certs with a longer lifetime.  The Kerberos is presumably tuned so tickets expire before you could reasonably grind through the process of revoking an identity.  If the cert lifetime is no longer so restricted, then is there relevant guidance to reference or repeat?

Does that help?

On Feb 3, 2011, at 11:07 AM, Pierre Pavlenyi wrote:

> <smime.p7s>_______________________________________________
> pkix mailing list
> [email-masked]

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 3 Feb 2011 16:49:48 -0500

Sean,

That doesn't address the question, which was on blacklisting (CRL or
OCSP) vs. whitelisting (short lifetime certs).

But for the revocation case if you compare apples to apples (same number
of certificate statuses returned), a CRL will never be bigger than an
OCSP response because OCSP is a much less efficient encoding of the
information.   Of course, if you build a CRL covering a million
certificates and build OCSP responses covering only 20 certificates
each, then a single OCSP response will be smaller than a single CRL.
But 50,000 20-cert OCSPs are much larger than one 1M-cert CRL, and
50,000 20-cert OCSPs are also much larger than 50,000 20-cert CRLs.

The blacklist vs. whitelist question can only be answered by modeling -
how many subscribers, how often do they use certs, how many relying
parties does a subscriber access, what is the accuracy of the RP clocks,
what products do they use, etc.  In theory, a CA could sign a renewed
certificate with 15 minute validity upon request from either the
subscriber or RP.  There is no reason for this to be inconvenient except
that current CAs, RP applications, and subscriber applications are not
designed to operate that way.  The bandwidth of sending new certs every
15 minutes will be higher than sending revocation info every 15 minutes,
but if subscribers are low-duty-cycle the "ticket" cert approach should
be fine if custom software development is not an issue.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sean Turner
Sent: Thursday, February 03, 2011 1:25 PM
To: Henry B. Hotz
Cc: pkix
Subject: Re: [pkix] Guidelines for Need for CRL/OCSP?

spt

On 2/3/11 1:22 PM, Henry B. Hotz wrote:
> If your certificates are always issued with really short lifetimes (a
few hours) it makes no sense to incur the deployment overhead of
maintaining CRL/OCSP infrastructure.  OTOH if they have lifetimes of a
year or more, it seems foolish not to.
>
> Is there any recommended policy covering this?  Any recommended
crossover point that could be referenced in another specification?

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 3 Feb 2011 16:57:48 -0500

Pierre,

Revocation is a means to an end, not an end in itself.

RPs should not have a use case or policy for "checking revocation", they
should have a policy for authentication freshness.  If the policy is
never to authenticate a user based on information more than 24 hours
old, that policy can be satisfied either by 1 year certs + 24 hour
revocation, or by 24 hour certs with no revocation.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pierre Pavlenyi
Sent: Thursday, February 03, 2011 2:08 PM
To: pkix
Subject: Re: [pkix] Guidelines for Need for CRL/OCSP?

Henry,

There is no "recommended" policy that I am aware of in terms of when you
should or should not use CRLs and/or OCSP.

If your Relying Party (RP) never has to see if the certificate has been
revoked, and are happy simply checking the validity and/or perform path
validation, then yes, you don't need to incur the overhead of a CRL/OCSP
infrastructure.  Note the "never" part of the previous sentence though.
If you don't have CRL and/or OCSP in your certificate, then the RP can
never check for certificate revocation; they can only check validity and
perform path validation.

If anywhere in your use case your RP needs to see if a Certificate has
been revoked, your stuck having to use CRL and/or OCSP.  At which point
you have to ask yourself another question:  what kind of response is my
RP looking for in terms of making a revocation determination?  This will
help you decide if you want CRL and/or OCSP.

Nail down your use case(s), and that will lead you down the right path
:-)

-----------------------
Pierre Pavlenyi, P.Eng

The opinions expressed here are strictly my own, and do not represent
those of any other party.

>> The opinions expressed in this message are mine, not those of 
>> Caltech, JPL, NASA, or the US Government.

---

From: Pierre Pavlenyi <[email-masked]>
Date: Thu, 3 Feb 2011 17:34:53 -0500

Henry,

Again, I have to ask if the TLS server you're authenticating your client to using the certs in question does revocation checking.  If no, then you don't need to supply a CDP or AIA-OCSP location.  If your TLS servers do revocation check, then I'm afraid you'll have to go with a CDP or AIA-OCSP location.

David Kemp also posted a reply to your original message that could help you out in terms of spec'ing out a CDP/OCSP infrastructure, should you need it.

As there are many OCSP implementations, you'd have to see how your particular OCSP product is configured to meet your needs, and how it can be tweaked.
-----------------------
Pierre

---

From: Pierre Pavlenyi <[email-masked]>
Date: Thu, 3 Feb 2011 17:36:34 -0500

David,

Yes, very true.  Essentially just another way to specify what your use case is, and fit your certificate profile to that use case :-)

-----------------------
Pierre Pavlenyi, P.Eng
514-638-8522

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 3 Feb 2011 17:38:12 -0800

> Again, I have to ask if the TLS server you're authenticating your client to using the certs in question does revocation checking.  If no, then you don't need to supply a CDP or AIA-OCSP location.…

Ignoring that part of your email may have given the wrong impression, sorry.  It's a valid, important point for how the server side use of such certs need to be set up.  I'm not sure if it needs to be mentioned in a client-side (of TLS) specification like KX509, but it probably wouldn't hurt.

As for my own deployment, my (unverified) expectation is that the server folk would rather not have to think about doing CRL/OCSP checking if they don't have to.

Absent an actual specification, or other official guidance, I agree that David Kemp did a really good job of putting things in perspective.  Thanks David!