headers
Henry B. Hotz | 3 Feb 2011 19:22
Picon
Picon
Favicon

Guidelines for Need for CRL/OCSP?

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.
Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply | 9 comments |
headers
Sean Turner | 3 Feb 2011 19:24

Re: Guidelines for Need for CRL/OCSP?

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:
> 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.
> Henry.B.Hotz <at> jpl.nasa.gov, or hbhotz <at> oxy.edu
>
>
>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
(Continue reading)

Permalink | Reply | 8 comments |
headers
Pierre Pavlenyi | 3 Feb 2011 20:07
Picon
Favicon

Re: 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.

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
ppavlenyi <at> carillon.ca

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mike Helm | 3 Feb 2011 20:34

Re: Guidelines for Need for CRL/OCSP?

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
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry B. Hotz | 3 Feb 2011 22:44
Picon
Picon
Favicon

Re: Guidelines for Need for CRL/OCSP?

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:

> 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 :-)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kemp, David P. | 3 Feb 2011 22:49

Re: Guidelines for Need for CRL/OCSP?

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: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kemp, David P. | 3 Feb 2011 22:57

Re: Guidelines for Need for CRL/OCSP?

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: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] 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.

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pierre Pavlenyi | 3 Feb 2011 23:34
Picon
Favicon

Re: Guidelines for Need for CRL/OCSP?

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 

On 2011-02-03, at 4:44 PM, Henry B. Hotz wrote:

> 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:
> 
>> Henry,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pierre Pavlenyi | 3 Feb 2011 23:36
Picon
Favicon

Re: Guidelines for Need for CRL/OCSP?

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
Identity Management Architect
ppavlenyi <at> carillon.ca
514-638-8522

On 2011-02-03, at 4:57 PM, Kemp, David P. wrote:

> 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: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
> Pierre Pavlenyi
> Sent: Thursday, February 03, 2011 2:08 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trevor Freeman | 4 Feb 2011 00:14
Picon

FW: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list


PLASMA - Policy Augmented S/Mime 

Description: Current S/MIME mechanisms provide cryptographic access to the message based on the
identity of the recipient at the time of transmission. Any additional access control enforcement
depends on the configuration of the recipients email client. Several Internet-Drafts have been
submitted that establish a more robust access control mechanism where cryptographic access to the
message is only granted after the access check.

This proposed working group would develop a framework for enforcing a more robust access control
mechanism, based on existing CMS, S/MIME and SAML-based policy enforcement standards. The working
group will also develop any necessary extensions to these base protocols specific to this problem space. 

Given some of the work in pkix relates to S/mime - this work may be of interest to some of you. 

Trevor

-----Original Message-----
From: IETF Secretariat [mailto:ietf-secretariat <at> ietf.org] 
Sent: Thursday, February 03, 2011 11:54 AM
To: IETF Announcement list
Cc: plasma <at> ietf.org; jimsch <at> nwlink.com; Trevor Freeman
Subject: New Non-WG Mailing List: plasma -- The PoLicy Augmented S/Mime (plasma) bof discussion list 

A new IETF non-working group email list has been created.

List address: plasma <at> ietf.org
Archive: http://www.ietf.org/mail-archive/web/plasma/
To subscribe: https://www.ietf.org/mailman/listinfo/plasma
(Continue reading)

Permalink | Reply | 0 comments |

Gmane