Subject: [pkix] Possible revocation delay issue with TLS stapling

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 26 Mar 2010 03:15:05 +0100

Hi,

While considering aspects of my multiple certificate status suggestions a
few days ago I realized that TLS stapling (the TLS Certificate status
Extension)of OCSP exacerbates the inherent "delay problem" when a
certificate is revoked, depending on how long the OCSP response is valid.

A malicious server that have its certificate revoked will still be able to
use an old unexpired OCSP response in its stapled status reports to the
clients for quite a while after the revocation, since the response will
usually be valid for several days.

The problem with this delay, which is inherent in the current revocation
system, is manageable when clients are requesting the OCSP response
directly, since new visitors will be protected when the OCSP responder is
updated; old visitors have likely already been attacked.

But with stapling the client have to rely on the server to provide a valid
and up-to-date OCSP response. A malicious server won't do that, it will
continue to use a valid, but obsolete and incorrect status indication.

My proposal is to create a new OCSP extension for stapled responses:

       - Servers must include this extension in requests to the OCSP
responder
       - The responder must include this extension in responses requested
this way, and must issue them with a shorter validity time, probably
associated with the turnaround for CRL/OCSP updates
       - Clients check for the extension in the stapled responses and  
discard
them if they do not have the extension and fetch the revocation
information direct instead (OCSP for site, CRL for intermediates)

The OCSP responders should be able to prefabricate the responses with the
new extension (in addition to the normal responses), and might even be
able to map them for GET requests, depending on how predictable the server
requests are.

Reducing the validity period for stapled OCSP responses will reduce the
window of opportunity for a malicious server operator. We can never
completely eliminate a revocation delay, but we should be able to reduce
it as much as possible.

Adding this will require updates of servers, OCSP responders and clients,
and can possibly be associated with my proposed update for Multiple OCSP
stapling.

I would also suggest that the TLS WG RFC4366-bis draft add an entry in the
CertificateStatus security considerations about this issue. My suggestion
(as a starting point) would be something like this:

"Certificate status entries have a validity period. A server can continue
to send the entry to clients as long as the entry is valid, even if the
server's certificate has been revoked since the entry was originally
created, according to a direct and up-to-date query to the issuer's
repository."

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Sean Leonard <[email-masked]>
Date: Fri, 26 Mar 2010 00:03:15 -0700

> Hi,

Hi Yngve,

Thanks for the e-mail. I think that your idea has merit. However, I have 
three general questions/concerns that perhaps you could think about and 
respond to:

1. Technically, neither OCSP responses nor CRLs expire. Both have 
thisUpdate and nextUpdate fields--see RFC 2560 and RFC 5280. While one 
can causally refer to OCSP responses or CRLs expiring, think about the 
implications. If a certificate is identified as "revoked" in an OCSP 
response or appears in a CRL without a reason code or with any reason 
code other than "certificateHold", that is it for the certificate--the 
certificate is dead forever. nextUpdate is basically just a 
recommendation about when new information should be available.

As a thought exercise, consider having a CRL (or OCSP response) at time 
t > nextUpdate date. You look for a certificate c, and c's serial number 
appears on the list/in the response as "revoked" due to 
"privilegeWithdrawn". You try to fetch a new CRL or OCSP response. No 
dice--network down. What should you do? Validation of c should fail, 
because it has been revoked (specifically, it has been revoked at least 
as of the thisUpdate date, and possibly earlier). The fact that the CRL 
or OCSP response is "old" does not mean that it should be ignored.

(Note that if the OCSP response is "old" and the OCSP response says 
"good", you may want to ignore that response, effectively treating it 
like expiration. But see point 3 below.)

2.(a) Your suggestion says that "servers" must include this extension in 
requests. How does the OCSP responder verify that the requester is a 
"server"? It cannot. So, if the CA is concerned about the staleness 
problem, why not just update OCSP information for all OCSP requests on a 
shorter interval?

2.(b) Technically your proposal addresses the security issue (where a 
malicious server would just find a "long", good response by lying about 
whether it's a server) by modifying the client's behavior to check for 
the proposed extension, and if it's not present, then fetch a response 
directly from the responder. But if the OCSP responder (run by the CA or 
on behalf of the CA) is so concerned about load, it can just increase 
the delay time back to the interval that it used to use, and put the 
extension in. The net effect is that we wouldn't see much change.

3. As a practical matter, most OCSP responders rely on a master CRL 
list, which is published with the same frequency as OCSP responder 
thisUpdate and nextUpdate fields. If you are so concerned about the 
delay problem, it may make more sense for the CA to update all 
revocation information sources more often.

Thanks,

Sean

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 26 Mar 2010 10:40:13 +0100

> problem, why not just update OCSP information for all OCSP requests on a

The operational cost of the short interval is higher.

So with that extension the server is saying : I'm highly sensitive *and* 
I'll optimize your network load, therefore trying to optimize your costs 
by giving me a long lived response is not the optimal strategy. Please 
give me a truer response of when you'll really be able to have fresher info.

What you write in details later is true, this is just an optimization, 
different strategy could be used to not need it, and it will work only 
if the client checks this extension.

One thing I can confirm is that, as often the next CRL is generated 
earlier that the next update in the CRL, I've seen one actual CA case 
where the policy is such that getting the latest CRL *could* get you a 
fresher info than getting an OCSP token.
So this is a specific case where the CA could make sure the staple OCSP 
request always hits the very latest CRL, whereas there's an interval 
where standard OCSP request are not yet updated to it, and using a still 
trustworthy (earlier than next update) CRL but not actually the very 
latest produced CRL.

So the question is just, is this sufficiently useful to deserve being 
added to the standard ?

Just one more thing, I'm thinking now that one strategy for the server 
can be to guarantee a 20 ms response delay on standard requests, but 
have a 1 or 2 seconds delay for a staple ready answer. It's then up to 
the client to decide if he wants slow but best, or fast but maybe less 
fresh.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Mar 2010 08:58:51 -0400

This is already covered in the 2560 Security Note.

"""
   The use of precomputed responses allows replay attacks in which an
   old (good) response is replayed prior to its expiration date but
   after the certificate has been revoked. Deployments of OCSP should
   carefully evaluate the benefit of precomputed responses against the
   probability of a replay attack and the costs associated with its
   successful execution.
"""

It's worth noting that this is a general problem, not specific to stapling, and the OCSP service can simply reduce the validity window if replay of stale-but-valid responses is a concern.  Further, clients are also free to reject a stapled OCSP response and fetch their own if they're not happy with the any of the producedAt, thisUpdate, or nextUpdate times.

I'd support broadening the security note, but I don't see a need for a new extension.

Also I'd point out that in many deployments OCSP is typically fed by CRLs anyway, so the determining time factors are set in CRL production not OCSP response production.  IOW, rejecting a stapled response in favor of a new response or CRL is probably equally likely to get you the same result as it is to get you a fresher result.

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Yngve N. Pettersen
>Sent: Thursday, March 25, 2010 9:15 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [pkix] Possible revocation delay issue with TLS stapling
>
>
>
>Hi,
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Mar 2010 09:02:28 -0400

Clients concerned with OCSP response freshness can always insist on nonces, and fall back on CRLs if the OCSP service won't support them.

-- Tim

>Jean-Marc Desperrier
>Sent: Friday, March 26, 2010 4:40 AM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
>
>Sean Leonard wrote:

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 26 Mar 2010 09:38:06 -0400

Another proof that the law of unintended consequences is operating in
full force.  Some time ago, guidance for how CRL nextUpdate should be
populated was discussed here.  One camp suggested that nextUpdate should
actually say when the next CRL would be issued; the other camp suggested
that because some applications treat nextUpdate as an expiration, CRL
issuers should, for example, put nextUpdate 7 days in the future for
CRLs that are actually issued every 24 hours, thereby treating scheduled
CRLs as unscheduled.

Rather than defining a new "suggested expiration" CRL extension for
applications to use as a default, the WG by inaction ratified the
treatment of nextUpdate as a de-facto expiration date.  The resulting
confusing consequences were predictable.

Dave

-----Original Message-----
From: Jean-Marc Desperrier

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 26 Mar 2010 10:36:04 -0400

The clients should nonce or should use the next update as a guideline.

This problem is not related to TLS alone.  Every relying party has to
deal with the freshness of revocation information. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Kemp, David P.
> Sent: Friday, March 26, 2010 9:38 AM
> Another proof that the law of unintended consequences is 
> operating in full force.  Some time ago, guidance for how CRL 
> nextUpdate should be populated was discussed here.  One camp 
> suggested that nextUpdate should actually say when the next 
> CRL would be issued; the other camp suggested that because 
> some applications treat nextUpdate as an expiration, CRL 
> issuers should, for example, put nextUpdate 7 days in the 
> future for CRLs that are actually issued every 24 hours, 
> thereby treating scheduled CRLs as unscheduled.
> 
> Rather than defining a new "suggested expiration" CRL 
> extension for applications to use as a default, the WG by 
> inaction ratified the treatment of nextUpdate as a de-facto 
> expiration date.  The resulting confusing consequences were 
> predictable.
> 
> Dave
> 
> 
> One thing I can confirm is that, as often the next CRL is 
> generated earlier that the next update in the CRL, I've seen 
> one actual CA case where the policy is such that getting the 
> latest CRL *could* get you a fresher info than getting an OCSP token.
>

---

From: Adam Langley <[email-masked]>
Date: Thu, 25 Mar 2010 22:38:00 -0400

> certificate is revoked, depending on how long the OCSP response is valid.

This is nothing new, but nor does your proposal really address it.

Consider an attacker, who holds a compromised key for x and who can
hijack your TCP connect to that host. They can choose not to support
status_request, wait for the HTTP connection to the OCSP responder and
substitute the longer term OCSP response which they cached previously.
Your design would only protect against the case where the attacker can
only hijack some TCP connections. Typically that would be done with
DNS poisoning, but that gives them everything. So it would have to be
the case that the client is resolving correctly, but the attacker is
sufficiently close to the real servers to be able to intercept their
traffic. It seems like a small case.

The current OCSP validity (typically 7 days) probably results from the
OCSP responder not wanting too much load. If OCSP stapling starts to
happen then the real solution is for the certificate holder to agree
with the issuer that they'll support stapling (thus reducing the load)
and the issuer won't ever issue responses valid for more than some
number of hours.

(Which reminds me: we should include CertificateStatus in cached info.)

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 26 Mar 2010 21:20:23 +0100

On Fri, 26 Mar 2010 14:02:28 +0100, Miller, Timothy J. <[email-masked]>  
wrote:

> Clients concerned with OCSP response freshness can always insist on  
> nonces, and fall back on CRLs if the OCSP service won't support them.

I am not aware of *any* commercial OCSP responder that will reply with a  
nonce if the client specifies one (Opera did between v8.0 and v9.2x). I  
suspect that it will only be supported in sensitive small scale  
deployments due to the computational cost of generating customized OCSP  
responses (each have to be individually signed).

Also, in contexts like TLS stapling, using a nonce will negate the desired  
benefits of less overhead and roundtrips, as well as that there will be no  
reduction in load on the OCSP responder.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 26 Mar 2010 16:31:21 -0400

DoD's OCSP service will respond to nonce queries.  That's anything but small scale, and is built on commercial products.

-- Tim

>From: Yngve N. Pettersen [mailto:[email-masked]]
>Sent: Friday, March 26, 2010 3:20 PM
>To: 'Jean-Marc Desperrier'; [email-masked]; Miller, Timothy J.
>Cc: [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 26 Mar 2010 13:17:16 -0500

[Why not pile on?  I think there's an angle not covered.]

As others have pointed out this is nothing new, nor special about OCSP
versus CRLs, and they have pointed out the workaround for RPs that care.

The more interesting point, I think, is that instantaneous revocation is
like password synchronization: hard.  You can get down to a window of
minutes.  But instantaneous revocation?  I don't believe that's feasible
in real world deployments.  Also, revoking certs is not enough if you
want instantaneous revocation!  You'd also want to slam existing
connections, and yet we have no protocol for doing that.

However, quick revocation has much higher costs than quick password
synchronization.  That's because making it possible to revoke certs
quickly means making more frequent use of online infrastructure, and
more frequent validation of signatures, whereas with password synch you
need only push changes as quickly as possible to a relatively few
servers.  Nowadays that extra cost may be in the noise, but it's not
nothing, and it's the reason that we have the ability to have OCSP
responses without nonces.

Think of OCSP as a Kerberos-like ticketing facility, with certs+OCSP
being like TGTs with long renewable lifetimes (corresponding to the
certs' notAfter) but short lifetimes (corresponding to OCSP response
freshness requirements / nextUpdate).  If you care about quick
revocation then you can just tune down the OCSP response freshness
requirements such that they fall within a time window whose size is
comparable to the time needed for revocation notices to reach all the
relevant OCSP responders.  The trick is to find just the right setting.

Nico
--

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 26 Mar 2010 22:30:08 +0100

>    probability of a replay attack and the costs associated with its

Similar language is not included in the TLS Extension document  
(RFC4366-bis)

> It's worth noting that this is a general problem, not specific to  
> stapling, and the OCSP service can simply reduce the validity window if  
> replay of stale-but-valid responses is a concern.

Yes, it is general and inherent in the system. However, in the case of  
"stapling" you have a situation where an authorized intermediate may turn  
malicious; we are not dealing with a normal MITM situation. The question  
is how to limit the damage potential?

> Further, clients are also free to reject a stapled OCSP response and  
> fetch their own if they're not happy with the any of the producedAt,  
> thisUpdate, or nextUpdate times.

Yes, that is one of the possibilities

> Also I'd point out that in many deployments OCSP is typically fed by  
> CRLs anyway, so the determining time factors are set in CRL production  
> not OCSP response production.  IOW, rejecting a stapled response in  
> favor of a new response or CRL is probably equally likely to get you the  
> same result as it is to get you a fresher result.

Having the issuer define the lifetime of stapled OCSP responses based on  
their update policies is IMO better than having the clients setting an  
essentially arbitrary freshness limit. To facilitate a reduced lifetime  
for stapled responses the issuer must either globally reduce the lifetime  
(which probably first require critical stapling support mass), or some way  
for the responder to distinguish the request for a stapling response or a  
normal client request.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 27 Mar 2010 01:13:17 +0100

On Sat, 27 Mar 2010 00:34:51 +0100, Peter Gutmann  
<[email-masked]> wrote:

> "Yngve N. Pettersen" <[email-masked]> writes:
>
>> nonce if the client specifies one (Opera did between v8.0 and v9.2x).
>
> Just to make sure I'm not misinterpreting this, you're saying that no  
> public/
> commercial OCSP responder (the DoD one isn't a public CA so doesn't fall  
> into
> this class) supports replay-attack protection with OCSP?

I have at least not encountered one (and I originally tried requiring it,  
and since converting to GET requests we do not request them), which does  
not necessarily mean they do not exist (as indicated by the DoD example).

However, IMO the processing cost of generating and signing OCSP responses  
that include a nonce is going to be quite heavy, meaning that is likely  
that only CAs with special security requirements (like the DoD), or a  
limited access load, will support, or require nonces.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Tomas Gustavsson <[email-masked]>
Date: Sun, 28 Mar 2010 11:51:13 +0200

On 03/27/2010 01:13 AM, Yngve N. Pettersen wrote:
>> commercial OCSP responder (the DoD one isn't a public CA so doesn't
>> fall into
> I have at least not encountered one (and I originally tried requiring
> it, and since converting to GET requests we do not request them), which
> does not necessarily mean they do not exist (as indicated by the DoD
> example).
>
> However, IMO the processing cost of generating and signing OCSP
> responses that include a nonce is going to be quite heavy, meaning that
> is likely that only CAs with special security requirements (like the
> DoD), or a limited access load, will support, or require nonces.

Just out of curiosity, what is considered limited access load here? 1000 
req/s, which is not very hard for supporting nounces and individually 
signed responses, or 50.000 req/s where it is more challenging?

Are there any good examples of that large scale OCSP services?

Cheers,
Tomas

---

From: "Bentkofsky, Michael" <[email-masked]>
Date: Mon, 29 Mar 2010 08:32:46 -0400

Tomas,

Yes, VeriSign's public OCSP service routinely gets more than 50,000 OCSP
requests per second. In fact, the service has gotten significantly more
than that at peak times, and the continued adoption of the OCSP protocol
suggests we'll be seeing significantly more still throughout the next
year. 

Thanks,
Michael Bentkofsky

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomas Gustavsson
Sent: Sunday, March 28, 2010 5:51 AM
To: [email-masked]
Subject: Re: [pkix] Possible revocation delay issue with TLS stapling

Cheers,
Tomas

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 09:03:11 -0400

A possible 'fix' to the revocation window problem has always been shorter certificate validity periods.  This has its own costs.

IMHO, however, timeliness revocation isn't the problem.  Experience with real world PKIs shows that sometimes revocation simply doesn't happen.  The CA may not be available, the incident may never get reported, or the system may simply fail in any of a dozen different ways up to and including lost database transactions.  Don't think it doesn't happen.

In short, relying on revocation to deny access may not be a good idea, at least for some systems.  Since the usual goal of authentication is to enable authorization, it can be safer to rely on the authorization system--i.e., revoke the account, remove the account's privileges, or invalidate the mapping between the shouldn't-be-used-any-more key and the account.  This is where X.509 gets in trouble; X.509 binds keys to names, and names are strongly (and naturally) mapped to accounts, so under X.509 the ways in which an authorization system can break the key-to-account mapping are very limited.  (The alternative--binding names to keys--has it's own set of problems, naturally.  They're different from X.509's, though.)

Either way, PKI authentication isn't enough by itself.  You need an equivalent authorization infrastructure to really make things work.

-- Tim

>Nicolas Williams
>Sent: Friday, March 26, 2010 1:17 PM
>To: Yngve N. Pettersen
>Cc: [email-masked]; [email-masked]
>Subject: Re: [pkix] [TLS] Possible revocation delay issue with TLS
>stapling
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 09:14:06 -0400

>Similar language is not included in the TLS Extension document

Sounds to me like it should be added.

>"stapling" you have a situation where an authorized intermediate may
>turn malicious; we are not dealing with a normal MITM situation. The question

A client concerned with this shouldn't rely on the stapled response.  However, I'd quibble that stapling presents a unique situation.  In any protocol (PKI-related or not), one should assume that *either* party can turn malicious at any time.

>for stapled responses the issuer must either globally reduce the
>lifetime (which probably first require critical stapling support mass), or some
>way for the responder to distinguish the request for a stapling response or
>a normal client request.

Clients already have unique freshness requirements.  I know of validation engines that won't accept CRLs beyond nextUpdate, and I know of equally many that will, and another number that let the user decide (and that's leaving out the implementations that simply don't treat revocation status as critical at all).  I know of validation engines that attempt to freshen CRLs at every validation, and those that only try to freshen once at the expiry of nextUpdate, and everywhere in between.  In addition, both clients and network proxies cache responses (OCSP and CRL), making the situation even more complex.

Which throws us back on "If you *really* care, insist on nonces."

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 29 Mar 2010 09:32:40 -0400

Tim,

In TLS model, the client's authorization check is basically checking the
server certificate DNS name against the expected DNS name.  I doubt
browser model will go beyond that.

Basically, the revocation freshness issue discussed in this thread is
not unique to TLS Server going rogue, except that a rogue server no
longer requires DNS poisoning assistance.

I do not think there is any change needed to the OCSP Specs either,
albeit 2560 could stand some clarification in the area of client side
processing.

The TLS folks may want to provide some guidance on CAs issuing server
certificates in terms of CRL next update field values and recommend to
the browsers to warn the user or deny the session if the revocation
information is past the next update field.

> Behalf Of Miller, Timothy J.
> Sent: Monday, March 29, 2010 9:03 AM
> To: 'Nicolas Williams'; Yngve N. Pettersen
> Subject: Re: [pkix] [TLS] Possible revocation delay issue 
> with TLS stapling
> 
> A possible 'fix' to the revocation window problem has always 
> been shorter certificate validity periods.  This has its own costs.
> 
> IMHO, however, timeliness revocation isn't the problem.  
> Experience with real world PKIs shows that sometimes 
> revocation simply doesn't happen.  The CA may not be 
> available, the incident may never get reported, or the system 
> may simply fail in any of a dozen different ways up to and 
> including lost database transactions.  Don't think it doesn't happen.
> 
> In short, relying on revocation to deny access may not be a 
> good idea, at least for some systems.  Since the usual goal 
> of authentication is to enable authorization, it can be safer 
> to rely on the authorization system--i.e., revoke the 
> account, remove the account's privileges, or invalidate the 
> mapping between the shouldn't-be-used-any-more key and the 
> account.  This is where X.509 gets in trouble; X.509 binds 
> keys to names, and names are strongly (and naturally) mapped 
> to accounts, so under X.509 the ways in which an 
> authorization system can break the key-to-account mapping are 
> very limited.  (The alternative--binding names to keys--has 
> it's own set of problems, naturally.  They're different from 
> X.509's, though.)
> 
> Either way, PKI authentication isn't enough by itself.  You 
> need an equivalent authorization infrastructure to really 
> make things work.
> 
> -- Tim
> 
> 
> >The more interesting point, I think, is that instantaneous 
> revocation 
> >is like password synchronization: hard.  You can get down to 
> a window 
> >of minutes.  But instantaneous revocation?  I don't believe that's 
> >feasible in real world deployments.  Also, revoking certs is 
> not enough 
> >if you want instantaneous revocation!  You'd also want to 
> slam existing

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 29 Mar 2010 09:54:33 -0400

That only gets you halfway there, since the nonce only ensures freshness
back to the OCSP responder, not the revocation authority.  The responder
itself can get revocation updates using any of the strategies you
mentioned (on every query - e.g. database backend, only after CRL
nextUpdate, somewhere in between, only after somewhere beyond
nextUpdate). 

If you *really, really* care, insist on CRLs.  But that would require
reasonable-sized CRLs (10Kb) with reasonably short nextUpdate (24h),
neither of which DoD currently produces.

It would also help to have a low-overhead (UDP-based with DTLS symmetric
integrity) CRL query protocol with an "I have this one, send me a newer
one if it exists" semantics.

Dave

-----Original Message-----
From: Miller, Timothy J

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 10:09:19 -0400

> (the DoD one isn't a public CA so doesn't fall into
>this class)

Waitaminit.  DoD may not be a public CA but it is a publicly accessible OCSP service.  :)

Of course, there's also DoD's External CA program, which is effectively public (per the published qualifying individuals criteria, I can't think of any class of subscribers that would be prohibited :).

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 10:12:59 -0400

Doug Wood at IEEE has done some good work on OCSP profiling for DoD, but I don't know if it's publishable or not.  The short summary as I understand it is TCP tuning is the real bottleneck, not cryptographic operations at the responder.

-- Tim

>Sent: Sunday, March 28, 2010 4:51 AM
>To: [email-masked]

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 10:23:08 -0400

>browser model will go beyond that.

I wouldn't be so sure:

http://www.cs.cmu.edu/~perspectives/index.html
https://addons.mozilla.org/en-US/firefox/addon/6415

Key continuity is quietly making it's way into the system as an additional security measure.  Whether or not a browser formally adopts KCM as a primary mechanism remains to be seen.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 29 Mar 2010 10:29:23 -0400

Well, the OCSP responder *could* be the CA, in which case assurance does go back to the revocation authority.  I don't think any PKIs beyond the smallest follow this trust model, but it's there.

>one if it exists" semantics.

I've been thinking about using RSS for delta CRL and/or full CRL publication.  That would get you the semantics, but the overhead is still a problem.

-- Tim

>Kemp, David P.
>Sent: Monday, March 29, 2010 8:55 AM