Subject: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Oct 2011 17:02:37 -0400

Thinking laterally on this issue.

The issue here seems to come up with the problem that OCSP does not have a
proper response code for 'does not exist', Now let us imagine for a moment
that we borrow from the prior art in DNSSEC and have an NSEC3 type
capability that provides a status for the 'gaps' between certificates.
Wouldn't this meet all the essential use cases?

The gaps could be specified either as gaps between certificate serial
numbers or gaps between cert hashes. I would like to see an OCSP extension
to allow the hash of the cert to be specified in any case.

So the old style OCSP token is (essentially)

   Sign (key, { {status-value, issuer, serial, {extensions}} } )

I would like to change that for certs that exist to:

   Sign (key, { {status-value, issuer, serial, {certhash, extensions}} } )

And if there is a query for a cert that does not exist and the request
indicates that you can process it, you would get back:

   Sign (key, { {non-existent, issuer, dummy-serial, {{start-indicator,
end-indicator}, extensions}} } )

This type of response would only ever be returned in an OCSP query response.
There would be no point whatsoever in stapling a non-existent OCSP token to
a TLS cert chain (OK not unless you were an attacker and you knew it would
cause the chain to break somehow, but we design it to avoid that happening)

It might be desirable to obfusticate the start and end indicators somewhat
to prevent cert population walking. But I rather doubt we would end up
hiding any information that can't be got using stats.

This has been in the DNSSEC spec for over a decade so it is almost certainly
unencumbered. It allows us to provide a signed response to every OCSP query
from static data. So why didn't we think of doing it from the start?

The only (minor) issue is that if there is a cert issued AFTER the date of
the OCSP token, the negative response token becomes invalid. Although that
turns out to be a moot point as if someone can hand you the negative
response token in response to the OCSP request, they can stop you getting
the valid OCSP token so you are hosed anyway.

---

From: <[email-masked]>
Date: Wed, 26 Oct 2011 17:45:41 -0400

Phil,

While this isn't really a use case, but wouldn't it seem from discussions of the last few days seem to indicate that user privacy is a big problem with OCSP? I wonder if the WG's efforts would be better spent focusing on tackling that problem. Or is this an issue that is seen as out of scope for this WG?

Thanks,
Walter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, October 26, 2011 4:03 PM
To: [email-masked]
Subject: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

The issue here seems to come up with the problem that OCSP does not have a proper response code for 'does not exist', Now let us imagine for a moment that we borrow from the prior art in DNSSEC and have an NSEC3 type capability that provides a status for the 'gaps' between certificates. Wouldn't this meet all the essential use cases?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Oct 2011 18:08:27 -0400

If user privacy is a concern then the solution is to move to OCSP stapling.

This is something that can probably be driven quite well by privacy audits
and appropriate privacy policy to encourage stapling.

But really, this information is no more privacy sensitive than any of the
other info sloshing round the net and the CA seeing it is probably a lesser
concern than the ISP, backbone provider etc.

At the end of the day the IP address will continue to give away the store.

On Wed, Oct 26, 2011 at 5:45 PM, <[email-masked]> wrote:

> Phil,****
>
> ** **
>
> While this isn’t really a use case, but wouldn’t it seem from discussions
> of the last few days seem to indicate that user privacy is a big problem
> with OCSP? I wonder if the WG’s efforts would be better spent focusing on
> tackling that problem. Or is this an issue that is seen as out of scope for
> this WG?****
>
> ** **
>
> Thanks,****
>
> Walter****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Phillip Hallam-Baker
> *Sent:* Wednesday, October 26, 2011 4:03 PM
> *To:* [email-masked]
> *Subject:* [pkix] An alternative proposal Was: Fwd: New Version
> Notification for draft-hamilton-cmr-00.txt****
>
> ** **
>
> Thinking laterally on this issue. ****
>
> ** **
>
> Wouldn't this meet all the essential use cases?****
>
> ** **
>
> ** **
>

-- 
Website: http://hallambaker.com/

---

From: [email-masked]
Date: Thu, 27 Oct 2011 10:22:46 +0200

Phil,

We both agree that the problem comes from the fact that OCSP does not have 
a proper response code for 'does not exist';

Since CertStatus is a CHOICE, we would need to move to OCSP v2 to add a 
new choice.

However, simply adding this response code to OCSP v2 would not be 
sufficient.

It would be necessary to advertise to the client that a given OCSP server 
has a direct access to the CA list of issued certificates,
and hence is is able to send back this new response code.

I would simply propose that we advertise this in a singleExtensions, by 
defining an extension.

Denis

> The issue here seems to come up with the problem that OCSP does not 
> have a proper response code for 'does not exist', Now let us imagine
> for a moment that we borrow from the prior art in DNSSEC and have an
> NSEC3 type capability that provides a status for the 'gaps' between 
> certificates. Wouldn't this meet all the essential use cases?
> 
> The gaps could be specified either as gaps between certificate 
> serial numbers or gaps between cert hashes. I would like to see an 
> OCSP extension to allow the hash of the cert to be specified in any 
case.
> And if there is a query for a cert that does not exist and the 
> request indicates that you can process it, you would get back:
> 
>    Sign (key, { {non-existent, issuer, dummy-serial, {{start-
> indicator, end-indicator}, extensions}} } )
> 
> This type of response would only ever be returned in an OCSP query 
> response. There would be no point whatsoever in stapling a non-
> existent OCSP token to a TLS cert chain (OK not unless you were an 
> attacker and you knew it would cause the chain to break somehow, but
> we design it to avoid that happening)
> 
> It might be desirable to obfusticate the start and end indicators 
> somewhat to prevent cert population walking. But I rather doubt we 
> would end up hiding any information that can't be got using stats. 
> 
> This has been in the DNSSEC spec for over a decade so it is almost 
> certainly unencumbered. It allows us to provide a signed response to
> every OCSP query from static data. So why didn't we think of doing 
> it from the start?
> 
> The only (minor) issue is that if there is a cert issued AFTER the 
> date of the OCSP token, the negative response token becomes invalid.
> Although that turns out to be a moot point as if someone can hand 
> you the negative response token in response to the OCSP request, 
> they can stop you getting the valid OCSP token so you are hosed anyway.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 27 Oct 2011 16:44:12 +0000

I agree you need a new choice hence v2 because todays good actually means not revoked.

The OSCP responder does not need access to the CA, just a list or set of lists for all the issued certificates.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 27, 2011 1:23 AM
To: [email-masked]
Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

Phil,

We both agree that the problem comes from the fact that OCSP does not have a proper response code for 'does not exist';

Since CertStatus is a CHOICE, we would need to move to OCSP v2 to add a new choice.

However, simply adding this response code to OCSP v2 would not be sufficient.

It would be necessary to advertise to the client that a given OCSP server has a direct access to the CA list of issued certificates,
and hence is is able to send back this new response code.

I would simply propose that we advertise this in a singleExtensions, by defining an extension.

Denis

> OCSP extension to allow the hash of the cert to be specified in any case.
>
> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Thu, 27 Oct 2011 12:59:27 -0400

As Paul pointed out earlier, site operators may well have different privacy goals than RPs. OCSP stapling pushes the responsibility of maintaining privacy to the site operators and doesn't do anything to help a RP to ensure their privacy (other than perhaps providing a way for their browser to tell them that a particular site is providing privacy protection measures since the browser could theoretically display a different chrome if it detects the OCSP stapling extension in the TLS response it gets from a site). Then end users could choose not to visit sites that don't provide this feature or choose to not perform revocation checking for such sites and accept the risk that the given site's certificate has been revoked. I think we will all agree this is hardly a desirable solution.

Thus I'm thinking it might be better to focus on solving the end to end privacy issues with OCSP first.

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, October 26, 2011 5:08 PM
To: Goulet, Walter
Cc: [email-masked]
Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

This is something that can probably be driven quite well by privacy audits and appropriate privacy policy to encourage stapling.

But really, this information is no more privacy sensitive than any of the other info sloshing round the net and the CA seeing it is probably a lesser concern than the ISP, backbone provider etc.

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 19:17:05 +0200 (MEST)

[email-masked] wrote:
> 
> As Paul pointed out earlier, site operators may well have different
> privacy goals than RPs. OCSP stapling pushes the responsibility of
> maintaining privacy to the site operators and doesn't do anything
> to help a RP to ensure their privacy (other than perhaps providing
> a way for their browser to tell them that a particular site is
> providing privacy protection measures since the browser could
> theoretically display a different chrome if it detects the OCSP
> stapling extension in the TLS response it gets from a site).
> Then end users could choose not to visit sites that don't provide
> this feature or choose to not perform revocation checking for such
> sites and accept the risk that the given site's certificate has
> been revoked.
> I think we will all agree this is hardly a desirable solution.

Actually, this *IS* a desirable solution and it is common practice in
the installed base.  All of the windows machines I'm using have
revocation checking disabled as shipped by the vendor, and for
the non-Microsoft-Browsers that I'm using, I have it manually
disabled.

So the way forward would be to get the multiple-OCSP stapling out
into the installed base and at some point in the future an option
in the browser to warn about sites that do not include stapled
OCSP in their TLS handshake.

> 
> Thus I'm thinking it might be better to focus on solving the
> end to end privacy issues with OCSP first.

The only universally workable solution that I see is to have
the cert owner acquire the OCSP responses and convey them
inband.  Everything else either voids privacy or difficult
or environment-specific to configure or simply won't work in
many environments (like Home users).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Oct 2011 13:21:01 -0400

Are we jumping the gun here?

Before we decide how to do it, is everyone in agreement that this is the way
forward?

Lets discuss that first and then work out how to handle the signalling. I am
sure that we can work that out and I am sure that there are much better
people to do that than me.

I see the following open issues:

1) Is the approach the right one?
2) Should the intervals be digest values or serial number values or both?
3) What should the backwards compatibility strategy be?

On Thu, Oct 27, 2011 at 12:44 PM, Trevor Freeman <
[email-masked]> wrote:

>  *I agree you need a new choice hence v2 because todays good actually
> means not revoked.*
>
> * *
>
> *The OSCP responder does not need access to the CA, just a list or set of
> lists for all the issued certificates. *
>
> * *
>
> [email-masked]
> *Sent:* Thursday, October 27, 2011 1:23 AM
> *To:* [email-masked]
> *Subject:* Re: [pkix] An alternative proposal Was: Fwd: New Version
> > https://www.ietf.org/mailman/listinfo/pkix****
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Oct 2011 10:42:49 -0700

> many environments (like Home users).

FWIW, I'm with Martin on this one. Site operators and relying parties may have different privacy goals, but they should have the same authentication goals. In general, a good model for PKIX would be "here is my cert and here is my freshest proof of validity". Compare that with "here is my cert and you have to go off looking for validity information on your own".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 27 Oct 2011 15:36:24 -0400

I can't see any problem with stapling from a privacy point of view.

A different user interface on the other hand, I think that would never fly.
How the bits get there should not be something that the typical consumer
wants to worry about.

All that 95% of users care about is how to get back to flinging birds at
pigs.

On Thu, Oct 27, 2011 at 1:42 PM, Paul Hoffman <[email-masked]> wrote:

> FWIW, I'm with Martin on this one. Site operators and relying parties may
> have different privacy goals, but they should have the same authentication
> goals. In general, a good model for PKIX would be "here is my cert and here
> is my freshest proof of validity". Compare that with "here is my cert and
> you have to go off looking for validity information on your own".
>
> --Paul Hoffman
>

---

From: <[email-masked]>
Date: Thu, 27 Oct 2011 15:49:04 -0400

The privacy issue with OCSP stapling is simply that some site operators may not care as much about user privacy and thus don't support that feature, even though an end user visiting that site is very concerned about privacy (and wants a 0% chance that a record of their visit to that site was created by the CA that owns the OCSP responder). Sites which go the extra mile to protect user privacy by supporting OCSP stapling should deserve an additional indicator in the browser to indicate to users that such additional protections are taking place. At least then users can avoid visiting sites which don't provide such protections.

Is there any reason why this shouldn't be done? Browsers already display different chrome for sites which purchase certificates that have been validated with a high degree of assurance (EV-SSL). I'd argue that sites which are taking steps to provide user privacy protections should get similar treatment since user privacy is a concept that a typical end user will embrace even more than they have for the extended validation that is done for EV-SSL certs.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, October 27, 2011 2:36 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

A different user interface on the other hand, I think that would never fly. How the bits get there should not be something that the typical consumer wants to worry about.

All that 95% of users care about is how to get back to flinging birds at pigs.
On Thu, Oct 27, 2011 at 1:42 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
On Oct 27, 2011, at 10:17 AM, Martin Rex wrote:

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 27 Oct 2011 16:12:18 -0400

From: Paul Hoffman
> FWIW, I'm with Martin on this one. Site operators and relying
> parties may have different privacy goals, but they should
> have the same authentication goals. In general, a good model
> for PKIX would be "here is my cert and here is my freshest
> proof of validity". Compare that with "here is my cert and

And of course the freshest proof of validity conveyed with the cert
could be a CRL instead of an OCSP response.  Inband conveyance is
another justification for CAs to limit the size of each individual CRL
to the size of a few certs, as opposed to the size of a 1080p HD mpeg of
a cat.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 27 Oct 2011 16:17:37 -0400

So, would users be presented with an indicator that the site
"protects user privacy" if the site supports OCSP stapling, even if
the site violated the user's privacy in every other way possible
(see "Privacy leakage on the Internet" at
http://www.ietf.org/proceedings/77/slides/plenaryt-5.pdf)?

A user requesting information from an OCSP responder may leak some
information to the responder, but there is no assurance that a site
protects a user's privacy simply because it supports OCSP stapling.
What if the sites that were the worst offenders in terms of sharing
user information with third parties were the first ones to rush to
implement OCSP stapling so that they could get the browser indicator
that implies that they "go the extra mile to protect user privacy"?

On 10/27/2011 03:49 PM, [email-masked] wrote:

The privacy issue with OCSP stapling is simply
that some site operators may not care as much about user
privacy and thus don’t support that feature, even though an
end user visiting that site is very concerned about privacy
(and wants a 0% chance that a record of their visit to that
site was created by the CA that owns the OCSP responder).
Sites which go the extra mile to protect user privacy by
supporting OCSP stapling should deserve an additional
indicator in the browser to indicate to users that such
additional protections are taking place. At least then users
can avoid visiting sites which don’t provide such
protections.

Is there any reason why this shouldn’t be done?
Browsers already display different chrome for sites which
purchase certificates that have been validated with a high
degree of assurance (EV-SSL). I’d argue that sites which are
taking steps to provide user privacy protections should get
similar treatment since user privacy is a concept that a
typical end user will embrace even more than they have for
the extended validation that is done for EV-SSL certs.

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 22:38:18 +0200 (MEST)

> the site violated the user's privacy in every other way possible

No, the idea is that this becomes the "expected behaviour", and that
those _not_ doing it get red-flagged, red-crossed, or earn themselves
a warning popup with a message:

  Privacy alert:
  this site did not provide a fresh proof for the validity of his
  server certificate.  It is suggested that you poll the CAs
  OCSP responder indicated in the server certificate, but that
  OCSP responder may be tracking that an when you're accessing this
  site -- so your consent for making that OCSP request is necessary.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 27 Oct 2011 16:51:02 -0400

Please read Walter's message again:

Sites which go the extra mile to protect user
privacy by supporting OCSP stapling should deserve an
additional indicator in the browser to indicate to users
that such additional protections are taking place.

How can this be interpreted as red-flagging those sites that do not
support OCSP stapling?  The lack of a red-flag warning is not an
"additional indicator".

I don't think the idea of red-flagging sites is any better.  Almost
no users would understand the privacy warning, and it still doesn't
address the question of why should this potential privacy problem be
called out for special user attention when there are so many worse
privacy violations that are being perpetrated.

On 10/27/2011 04:38 PM, Martin Rex wrote:

David A. Cooper wrote:

Privacy alert:

-Martin
.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 28 Oct 2011 10:20:36 +0100

On Thursday 27 Oct 2011 18:42:49 Paul Hoffman wrote:
<snip>
> goals. In general, a good model for PKIX would be "here is my cert and
> here is my freshest proof of validity". Compare that with "here is my cert
> and you have to go off looking for validity information on your own".

A few months ago I was investigating the roadmap for adding OCSP Stapling 
support to the nginx webserver.  One site operator chimed in with his opinion 
[1], which clearly doesn't favour "here is my cert and here is my freshest 
proof of validity".

When a webserver disables OCSP Stapling by default (or enables it by default 
but provides an option to disable it), what incentive does the site operator 
have to enable it (or to not disable it)?

[1] http://mailman.nginx.org/pipermail/nginx-devel/2011-June/000958.html

"As an user, I would prefer it disabled and available as an optional
module and not part as core.
As of Apache 2.3 OSCP Stapling is disabled by default too.

I don't really get why use an high-performance web server to handle
queries only saving money to certification authorities.
So we pay like $100/200 for the SSL certificate, and then we pay again
server and bandwidth fees to answer OSCP ?

Clients have time to wait OSCP answer from CA and in the other side,
nginx server is already very busy so it is probably not a good idea to
load it with bonus features."

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Oct 2011 07:15:21 -0700

> server and bandwidth fees to answer OSCP ?

That sounds like he thought that you were requiring him to do OCSP responding, not OCSP stapling. Call it "OCSP stapling" might have confused him as it has some folks in the IETF. A better term would be "validity proof stapling".

> have to enable it (or to not disable it)?

If the PKIX community (whatever that is) moves from a "RP pulls validity info from CA" model to a "RP gets validity info from validated host" model, then the hosts will have an incentive. Until then, their incentive will remain as they are now, and so will the incentives for CAs. This thread is a discussion of how the model might change.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Oct 2011 16:35:18 +0200 (MEST)

> load it with bonus features."

That is based on a complete misunderstanding of the technology at hand.

The client will have to do the OCSP download to arbitrary OCSP servers
*during* the TLS handshake (i.e. stalling the server on the handhake),
and that is for unpredictable OCSP servers with no contractual
aggreements for connectivity and availability.

The TLS server, on the other hand, can perform OCSP retrieval for
his very own cert with an infrequent recurring asynchronous operation
(e.g. once every few hours), it is always exactly the same OCSP server,
the CA has a contractual obligation towards the Server cert purchaser
to provide this service, and the Server operater can select a suitable
CA with an OCSP service quality and connectivity that meets the servers
expectations.

In case that the asynchronous OCSP retrievel job on the Web Server fails,
it will *NOT* immediately result in TLS handshake failures -- instead,
the server can continue to send the previous OCSP response.  So
the whole system is much more fault tolerant and provides a support
window to fix technical problems with the OCSP several hours before
it will affect the availability of the TLS server.

Anyone with a clue about "high performance servers" should know that
having to perform under-the-cover communication with third-parties
*during* the handshake is a real performance killer and seriously
impairs the robustness (and therefore availability) of the service.

-Martin

---

From: Kyle Hamilton <[email-masked]>
Date: Fri, 28 Oct 2011 09:14:47 -0700

On Wed, Oct 26, 2011 at 2:02 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> proper response code for 'does not exist',

I have no problem at all with improving OCSP, as a separate item.  I
really want to improve it, actually.  The problem is that by
definition, any OCSP responder which can respond with a "does not
exist" will be required to respond in that manner for any and every
certificate serial number which is not listed on the CRL.  CRL cannot
meaningfully feed such a responder.

 Now let us imagine for a moment
> end-indicator}, extensions}} } )

How about,

Sign(key, { {status-value, issuer, serial, { certhash,
extended-status-value, extensions } } })

and

Sign(key, { { status-value REVOKED, issuer, serial, {certhash,
extended-status-value NeverIssued, otherextensions } } })

-Kyle H

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 27 Oct 2011 21:59:29 +0200

On 10/27/2011 06:44 PM, Trevor Freeman wrote:
>
> *I agree you need a new choice hence v2 because todays good actually means not revoked.*
>
you just can add an extension that says "when I said revoked, it really means more, it doesn't even 
exist"
>
> **
>
> **
>
> *The OSCP responder does not need access to the CA, just a list or set of lists for all the issued 
> certificates.*
>
It needs some information that can be used to verify if a cert had been issued.
a strong one way function (in oder to avoid the word hash) towards that info to see
whether a cert is valid for example.

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 28 Oct 2011 12:59:54 -0400

Applications already disable links and images to minimize tracking -
disabling OCSP queries would seem to fall into the same beaconing
category and shouldn't require the user to take additional action beyond
what already exists.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Cooper
Sent: Thursday, October 27, 2011 4:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

	Sites which go the extra mile to protect user privacy by
supporting OCSP stapling should deserve an additional indicator in the
browser to indicate to users that such additional protections are taking
place. 

I don't think the idea of red-flagging sites is any better.  Almost no
users would understand the privacy warning, and it still doesn't address
the question of why should this potential privacy problem be called out
for special user attention when there are so many worse privacy
violations that are being perpetrated.

	David A. Cooper wrote:

		So, would users be presented with an indicator that the
site
		"protects user privacy" if the site supports OCSP
stapling, even if
		the site violated the user's privacy in every other way
possible

	No, the idea is that this becomes the "expected behaviour", and
that
	those _not_ doing it get red-flagged, red-crossed, or earn
themselves
	a warning popup with a message:
	
	  Privacy alert:
	  this site did not provide a fresh proof for the validity of
his
	  server certificate.  It is suggested that you poll the CAs
	  OCSP responder indicated in the server certificate, but that
	  OCSP responder may be tracking that an when you're accessing
this
	  site -- so your consent for making that OCSP request is
necessary.
	
	-Martin
	.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Oct 2011 12:51:37 +0000

On Friday 28 Oct 2011 15:15:21 Paul Hoffman wrote:
> > support to the nginx webserver.  One site operator chimed in with his
> > opinion [1], which clearly doesn't favour "here is my cert and here is
> > my freshest proof of validity".
> 
> It is quite believable that one site operator might not like the idea, yes.
> However, from his response, it is not clear that he understood your
> proposal.

Good point.  I did assume that he knew what I was talking about.

> He said:
> That sounds like he thought that you were requiring him to do OCSP
> responding, not OCSP stapling.

I took "pay...bandwidth fees to answer OCSP" to be referring to the extra 
~1-2K he would need to serve for each TLS handshake that contains a stapled 
OCSP Response.

I understood his complaint to be: Clients can fetch this data from the CA, so 
why should he be required to serve it?  The CA already received money for the 
cert, so the CA should foot the bill for serving the revocation information.
(IMHO, this complaint is not entirely unreasonable).

> Call it "OCSP stapling" might have confused him as it has some folks in the
> IETF. A better term would be "validity proof stapling".
> 
> > When a webserver disables OCSP Stapling by default (or enables it by
> > default but provides an option to disable it), what incentive does the
> > site operator have to enable it (or to not disable it)?
> 
> If the PKIX community (whatever that is) moves from a "RP pulls validity
> info from CA" model to a "RP gets validity info from validated host"
> model, then the hosts will have an incentive. Until then, their incentive
> will remain as they are now, and so will the incentives for CAs. This
> thread is a discussion of how the model might change.
> 
> --Paul Hoffman

Rob Stradling

---

From: Michael Myers <[email-masked]>
Date: Mon, 31 Oct 2011 06:36:23 -0700

All,

On this subject, note also RFC 4806, where Haanes Tschofenig and I  
designed and documented the same technique for IKEv2.

http://tools.ietf.org/html/rfc4806

The limited scale of its adoption is likely due to the fact that IKE  
uses UDP and consequently there exists fragmentation issues.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 31 Oct 2011 18:35:48 +0100 (MET)

Rob Stradling wrote:
> I understood his complaint to be: Clients can fetch this data from the CA,
> so why should he be required to serve it?  The CA already received money
> for the cert, so the CA should foot the bill for serving the revocation
> information. (IMHO, this complaint is not entirely unreasonable).

I checked the current proposal for an TLS extension for stapling
multiple OCSP responses:
  http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-02

and single-OCSP response:
  http://tools.ietf.org/html/rfc6066#section-8

and I consider both pretty disappointing and useless for the purpose
of more efficient OCSP processing.

The idea to require the server stalling the TLS handshake to obtain an OCSP
response from some arbitrary client-specified OCSP responder with
some arbitrary OCSP request attributes is IMHO a very bad idea for
the general use case; I would never want my servers to perform such
requests and can understand other server operaters who do not want
this either.

A generally useful TLS extension for OCSP response stapling should be a 
"take it or leave it approach", i.e.  the server provides OCSP stapling
for exactly the (first) OCSP responder in the OCSP AIA resources of the
certificate(s) of the server certificate chain and both server and client
can cache these responses for a few hours, and the client can indicate
whether it still has cached OCSP-responses available and for which
server certificate chain, which would obviate the sending of the
stapled OCSP responses with each and every handshake (such as
abbreviated TLS handshakes, aka session resumes) and still work
successfully/transparently for credentials updates on the server.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 31 Oct 2011 10:53:43 -0700

> successfully/transparently for credentials updates on the server.

s/a few hours/as long as they want/, but yes. The purpose of stapling is not to change who does OCSP, but to make validation more sane for RPs. If an RP would have cached its validation effort for a few hours, then the server doesn't need to be any faster than that.

--Paul Hoffman