Subject: [pkix] Optimizing OCSP - Time for some spec work ?

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Oct 2019 08:53:59 -0600

Hi PKIX Gurus,

I am working on trying to optimize the OCSP protocol to better fit some 
of the use-cases we have. In particular, for very large PKIs (i.e., few 
hundreds million certificates valid at any given time), the OCSP 
protocol does not scale well. In fact, taking into consideration how we 
operate OCSP responders today, the larger the PKI is, the higher the 
costs of providing a good revocation infrastructure.

Our work is focusing on two considerations:

  * Optimizing for the common case (non-revoked certificate). In
    particular, for certificates that have no revocation information, we
    do not have to provide specific responses for each individual
    certificate (as we do in the revoked case), but we can provide
    responses for ranges of certificates where the status is not
    revoked. In a PKI with a population of 100M certificate and a
    revocation rate of 5%, using "range" response types reduces the need
    for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N
    is the population of revoked certificates). This allows to
    pre-generate responses more quickly, allows for lower costs of
    running the revocation infrastructure, and it is better for the
    planet :D

  * Providing Full Chain responses. Although single OCSP responders can
    be authoritative for their own CA only, they can attach the
    responses for the full chain as additional data. If we add this
    possibility, then a single OCSP request can provide the
    client/server with the full chain of certificates up to the Root.
    This might be tricky in complex scenarios where cross-certification
    is used, but it would definitely work for the Web PKI and IoT use cases.

Given these considerations - and the fact that large PKIs are being 
deployed, today, for the IoT case - we would like to discuss the current 
status of OCSP and our proposal for moving forward with a more efficient 
protocol at the meeting in Singapore (IETF 106) - LAMPS WG. If you are 
interested in the topic and/or would like to contribute, we will be 
presenting there - come and join the discussion!

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 24 Oct 2019 17:13:59 +0200

>    running the revocation infrastructure, and it is better for the

I don't see how that can work if you're not allowed to return good
for a non-issued certificate and that the serial numbers should
be random.

Kurt

---

From: Denis <[email-masked]>
Date: Thu, 24 Oct 2019 17:19:31 +0200

Hello Max,

What you are proposing is not an optimization of OCSP but something 
different, so please don't call it "optimizing OCSP".

    "Optimizing for the common case (non-revoked certificate)" by
    pre-computing responses has implications about the timeliness of the
    revocation date and time.
    As Kurt just mentioned, I don't see either how this can work given
    the fact that certificate serial numbers should be random.

    "Providing Full chain responses" seems to be close to RFC 5055:
    Server-Based Certificate Validation Protocol (SCVP).
    When you take a look at the complexity of this protocol, the key
    question that comes to my mind is what kind of
    differences/simplifications you would be expecting.

As you know, the best way to continue the discussion would be to propose 
a title, an introduction and possibly an overview.
RFC 5055 (as well as OCSP) would need to be positioned in the Introduction.

Denis

> Hi PKIX Gurus,
>
> I am working on trying to optimize the OCSP protocol to better fit 
> some of the use-cases we have. In particular, for very large PKIs 
> (i.e., few hundreds million certificates valid at any given time), the 
> OCSP protocol does not scale well. In fact, taking into consideration 
> how we operate OCSP responders today, the larger the PKI is, the 
> higher the costs of providing a good revocation infrastructure.
>
>     particular, for certificates that have no revocation information,
>     we do not have to provide specific responses for each individual
>     revocation rate of 5%, using "range" response types reduces the
>     need for calculating OCSP responses from 100M to 1M (i.e. 2N + 1
>     where N is the population of revoked certificates). This allows to
>   * Providing Full Chain responses. Although single OCSP responders
>     can be authoritative for their own CA only, they can attach the
>     This might be tricky in complex scenarios where
>     cross-certification is used, but it would definitely work for the
>     Web PKI and IoT use cases.
>
> deployed, today, for the IoT case - we would like to discuss the 
> current status of OCSP and our proposal for moving forward with a more 
> efficient protocol at the meeting in Singapore (IETF 106) - LAMPS WG. 
> If you are interested in the topic and/or would like to contribute, we 
> will be presenting there - come and join the discussion!
>
> Cheers,
> Max
>
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Oct 2019 02:00:35 +0000

Denis <[email-masked]> writes:

>different

It is very definitely an optimisation of OCSP, and in particular one that's 
far better than the current "optimisation" of droppping the nonce and 
accepting replayed responses as current as a hack to deal with OCSP's 
non-scalability.

The only concern I'd have is that it'd need to have some data on how
effective it'll actually be in practice.  Let's say you have x% loading due
to revocations, so x% of all certs are revoked, and also y% loading of cert
statuses, so y% of certs are actively queried via OCSP.  At what point does
x get high enough that the fragmentation of the serial number ranges negates
any specific benefit from pre-generating responses for a subrange, and how 
much mitigation do different y values provide for the fragmentation issue?

So it'd need a research publication to demonstrate there's a benefit, and
under what conditions, after which it'd certainly be a better bugfix for
OCSP than the accept-replayed-responses kludge.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Oct 2019 02:04:11 +0000

Kurt Roeckx <[email-masked]> writes:

>I don't see how that can work if you're not allowed to return good for a 
>non-issued certificate 

RFC 6960 says:

   The "good" state indicates a positive response to the status inquiry.  
   At a minimum, this positive response indicates that no certificate
   with the requested certificate serial number currently within its
   validity interval is revoked.  This state does not necessarily mean
   that the certificate was ever issued or that the time at which the
   response was produced is within the certificate's validity interval.

So you're explicitly permitted to return "good" for a non-issued certificate.
   
>and that the serial numbers should be random.

How would the way serial numbers are generated affect things?  In other
words, to reverse your comment, how would it *not* work with random serial
numbers?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Oct 2019 02:07:58 +0000

Dr. Pala <[email-masked]> writes:

>Providing Full Chain responses.

OCSP already does this, and has done since day 1.  That was the Identrus 
value proposition, they would do all the checking for you and return
everything in a single response.  It proved... less than wildly popular.

Peter.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Fri, 25 Oct 2019 02:12:22 +0000 (UTC)

FWIW, RFC 5055 implementations are quite rare, and would be better served being replaced with a simple Rest API.

  On Thu, Oct 24, 2019 at 11:19, Denis<[email-masked]> wrote:   _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Oct 2019 02:20:28 +0000

Todd E. Johnson <tejohnson=[email-masked]> writes:

>FWIW, RFC 5055 implementations are quite rare

"Quite rare" is being generous :-).  Some portion of the USG played with one
years ago, I think they had some Java code done by a government contractor,
and AFAIK that's it.  I got the impression at the time that it was more a 
means of getting vendor lock-in than anything else, i.e. using a protocol
that nothing else implemented ensured you got the contract because there was
no alternative

I'm not sure if Denis was being deliberately disingeneous with the 5055 
reference...

Peter.

---

From: "Todd E. Johnson" <[email-masked]>
Date: Fri, 25 Oct 2019 02:26:11 +0000 (UTC)

Oh,
You mean the following?
https://github.com/GSA/ficam-scvp-testing/tree/master/utilities/vss2

Otherwise, I tried to document other implementations at the time:
https://github.com/grandamp/SCVPAPI/blob/master/README.md

 

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 25 Oct 2019 02:34:41 +0000

>https://github.com/GSA/ficam-scvp-testing/tree/master/utilities/vss2

Thanks for the link, not that one specifically but as that site points out 
it was the US Treasury that pushed for it.  I couldn't remember which 
department it had been, just that it was some part of the USG.  I 
encountered it with some European company that seemed to have more GSA 
material plastered over their web site than most US vendors did, which 
indicated what market they were trying to sell into.

Peter.

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 25 Oct 2019 08:57:55 -0600

Hi Peter,

That is a great point. I would like to explore it with you.

Yes, it is possible. However, I think that did not work for two reasons. 
If I am not mistaken (please correct me if I am wrong), the first reason 
is that the client has to explicitly request the responses for the 
certificates in the chain (i.e., multiple requests). The second reason, 
I think, is related to the trust model: the responder have to sign 
responses from different CAs instead of just one - so how can I trust 
the response from an intermediate CA to guarantee me that all CAs above 
me (me included) are not revoked ? It might work if you use a RootCA to 
sign the responses... but it is not common to use the RootCA keys 
directly... In addition to that, each certificate carries the indication 
where its revInfo can be retrieved, therefore clients tend to make 
single requests to the different OCSP responders one by one (it might be 
the same, but it might be different). In addition to this, there might 
be implications about pre-computed responses

As far as I know, as you say, it is possible, but I have not seen 
clients actually querying for multiple certificates - have you ?

A different model would be for the OCSP responder to be able to retrieve 
(maybe if requested by the client w/ an extension) the additional 
responses (as the client do today) at regular intervals and attach them 
together with the response for the request from the client. This allows 
to have different validity period of the responses and no real 
trust-related dependencies (i.e., the OCSP responder will re-fetch the 
responses that are expired and maybe cache them for the validity period 
or part of it).

 From a developer point of view, maybe this approach can provide easier 
(for the developer) query mechanism (i.e., "What is the Revocation 
Status of Certificate X ? Can you include the responses for the full 
chain ?" instead of ""What is the Revocation Status of Certificate X, Y, 
and Z ?" - not being sure if this is the right responder for all of them)).

Does that make sense ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Niklas Matthies <[email-masked]>
Date: Fri, 25 Oct 2019 17:20:19 +0200

Hi Max,

Just to chime in regarding the first reason: OCSP responses are 
allowed to include additional single responses that weren't explicitly 
requested by the client, see RFC 6960 section 4.2.2.3 last paragraph.
To make the additional responses optional (controlled by the client), 
a corresponding request extension could be defined. Hence that aspect 
could be covered by specifying a profile of the current OCSP protocol.

Cheers,
Niklas

On Fri 2019-10-25 at 08:57h, Dr. Pala wrote on pkix:
>Yes, it is possible. However, I think that did not work for two 
>reasons. If I am not mistaken (please correct me if I am wrong), the 
>first reason is that the client has to explicitly request the 
>responses for the certificates in the chain (i.e., multiple requests). 
>The second reason, I think, is related to the trust model: the 
>responder have to sign responses from different CAs instead of just 
>one - so how can I trust the response from an intermediate CA to 
>guarantee me that all CAs above me (me included) are not revoked ? It 
>might work if you use a RootCA to sign the responses... but it is not 
>common to use the RootCA keys directly... In addition to that, each 
>certificate carries the indication where its revInfo can be retrieved, 
>therefore clients tend to make single requests to the different OCSP 
>responders one by one (it might be the same, but it might be 
>different). In addition to this, there might be implications about 
>pre-computed responses
>
>A different model would be for the OCSP responder to be able to 
>retrieve (maybe if requested by the client w/ an extension) the 
>additional responses (as the client do today) at regular intervals and 
>attach them together with the response for the request from the 
>client. This allows to have different validity period of the responses 
>and no real trust-related dependencies (i.e., the OCSP responder will 
>re-fetch the responses that are expired and maybe cache them for the 
>validity period or part of it).
>
>chain ?" instead of ""What is the Revocation Status of Certificate X, 
>Y, and Z ?" - not being sure if this is the right responder for all of 
>them)).
>
>Does that make sense ?
>
>Cheers,
>Max
>
>

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 25 Oct 2019 10:06:31 -0600

Hi Peter,

> OCSP than the accept-replayed-responses kludge.

Yes, that is the right thing to do. I am trying to work on a quick 
implementation so that I would collect some practical data around it. 
However, I think there might be some theoretical approach we can also 
use to quantify benefits based on, at a minimum, projected size of the 
PKI and the number of revoked certificates: the lower the revocation 
ratio is (revoked certificates / total valid population), the lower the 
costs of pre-computation for the whole population is.

It is interesting to notice that this solution makes the costs 
associated with the revocation infrastructure to be directly correlated 
to the number of revoked certificates, instead of the number of issued 
certificates, thus shifting the paradigm quite a bit (thus with good 
architecture for your PKI that minimizes revocation events, this 
solution can provide very economic revocation information distribution.)

FYI, I started the conversation also in the LAMPS WG and will present 
(hopefully we will get the slot) on this issue at the Singapore's 
meeting - there we are trying to raise interest in working on this topic 
- so that we can understand what are the chances there to make the world 
a better place :D After that, depending on how much interest we get, we 
might go with SecDispatch or IESG individual submission (we need some 
standardization for our industry at least).

Last but not least, I am now thinking about demonstrating the benefits 
related to this idea and one of the aspects to consider is about CRLs 
vs. OCSP. Also in that case, the benefits of deploying OCSP is only when 
CRLs grow beyond a certain size - the problem here is that, although we 
can come up with a threshold figure there, clients would never know, 
beforehand, which path is the optimal one ... (CRLs, OCSP v1, or OCSP v2 
?) ... at any given time (i.e., that changes with the changes in the 
trust infrastructure)

In case there is interest, would you like to participate in the effort ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 25 Oct 2019 12:51:37 -0600

Hi Niklas,

thanks for pointing that out - that paragraph is quite difficult to 
interpret correctly (I guess that is why nobody is attaching extra OCSP 
responses). In fact the text reads:

    The response SHOULD NOT include any additional
        SingleResponse elements, but, for example, OCSP responders that
        pre-generate status responses might include additional SingleResponse
        elements if necessary to improve response pre-generation performance
        or cache efficiency (according to [RFC5019], Section 2.2.1).

and it starts with a SHOULD NOT :D I guess this was an attempt to 
provide some capability here, but did not provide the use-case for it. - 
therefore support for "extra" responses is quite interesting. When 
reading this paragraph, my first reaction as a developer is NOT to 
implement that feature.

Also, if you think about it, there is a Trust problem - why shall I 
trust this CA's responder to provide responses up in the chain ?

If the inclusion of the additional responses would encapsulate their 
authentication information, then we could trust those additional 
responses... otherwise, if not locally configured, the responder is not 
authoritative for other CAs. If your OCSP responder supports multiple 
CAs and could be authoritative for all of them... which certificate will 
your responder use to sign the response (i.e., shall it use the 
certificate that makes it authoritative for the requested certificate or 
the one that makes it authoritative for the issuing CA status ?)

Therefore, although it is technically possible, I think the way it is 
specified now it is not really usable. Do you know of implementation 
that use this feature? If so, do you know how they solved the Trust 
issue here ?

Ultimately, coming to using extensions in the requests - that is an 
interesting option (what about attaching the responses of the upper 
links in the chain as an extension in the basic response ?), however 
this complicates the implementation server-side ==> In general, whenever 
you add the possibility for the client to influence the content of the 
response, responses need to be generated according to the 
client-provided parameters, and, therefore, they cannot be pre-computed 
(which I think can be easily implemented if the number of target 
responses is sufficiently limited - i.e., your revoked certificates 
population is small enough that live responders calculate, cache, and 
update all responses 'live' with great performance and that do not 
require lots of resources).

Thanks again for the feedback!

Also, would you like to contribute to the effort shall we (IETF) decide 
to tackle this problem ?

Cheers,
Max

On 10/25/19 9:20 AM, Niklas Matthies wrote:
>> responses for the certificates in the chain (i.e., multiple 
>> requests). The second reason, I think, is related to the trust model: 
>> the responder have to sign responses from different CAs instead of 
>> just one - so how can I trust the response from an intermediate CA to 
>> certificate carries the indication where its revInfo can be 
>> retrieved, therefore clients tend to make single requests to the 
>> different OCSP responders one by one (it might be the same, but it 
>> might be different). In addition to this, there might be implications 
>> about pre-computed responses
>>
>> additional responses (as the client do today) at regular intervals 
>> and attach them together with the response for the request from the 
>> client. This allows to have different validity period of the 
>> responses and no real trust-related dependencies (i.e., the OCSP 
>> responder will re-fetch the responses that are expired and maybe 
>> cache them for the validity period or part of it).
>>
>> From a developer point of view, maybe this approach can provide 
>> easier (for the developer) query mechanism (i.e., "What is the 
>> Revocation Status of Certificate X ? Can you include the responses 
>> for the full chain ?" instead of ""What is the Revocation Status of 
>> Certificate X, Y, and Z ?" - not being sure if this is the right 
>> responder for all of them)).
>>
>> Does that make sense ?
>>
>> Cheers,
>> Max
>>
>>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Russ Housley <[email-masked]>
Date: Fri, 25 Oct 2019 15:20:23 -0400

> FWIW, RFC 5055 implementations are quite rare

It simply too us too long to proguce SCVP.  We missed the window on that one...

Russ

---

From: Niklas Matthies <[email-masked]>
Date: Fri, 25 Oct 2019 23:49:46 +0200

Hi Max,

You are right that the trust problem would be difficult, if not 
impossible, to solve when using additional single responses. Placing 
the additional responses in a response extension, as a sequence of 
basic responses signed by the respective authorized responders, 
certainly is a better idea.

However, I now see the following considerations:

1) If the up-chain responders all do the same thing, then it would be 
sufficient (and advisable) to only add one additional response for the 
immediate issuer, as that response will in turn include a response for 
the issuer's issuer, and so on. In other words, when assembling the 
response, the implementation should check which responses it needs to 
add itself and which are already part of the responses being added, to 
avoid unnecessary duplication. (More generally: to keep the response 
size linear in the chain length instead of becoming quadratic.) 
Conversely, clients would have to be prepared to collect all needed 
responses from that nested structure.

2) In case of such a nesting, the more nested a response the older it 
will usually be, due to caching at each responder. That would have to 
be taken into account when assembling the outer response, potentially 
having to replace a nested response by adding a fresher version of 
some inner response at the outer level. A similar issue exists with 
regard to nextUpdate field when a nested response expires before the 
outer one does. This increases the overall complexity.

3) When storing OCSP responses for long-term validation (e.g. in 
signature extensions for archiving), one may want to unpack the inner 
responses before storing them, so that validators are not required to 
support the nested format. However, because the inner responses are 
covered by the outer responder signature, they cannot be removed from 
the inner structure, which means they would need to be duplicated to 
also store them at the outer level, increasing the overall size.

For those reasons, in particular the fact that the structure cannot be 
disassembled without breaking the outer signature, it would really be 
simpler and more flexible to just have a linear sequence of regular 
basic responses. This could be achieved via a new response type 
(responseType in ResponseBytes) for which the response bytes consist 
of a sequence of basic responses instead of just one basic response. 
(Some additional guidance would have to be given for the certs field 
of BasicOCSPResponse so as to avoid redundancy there.)

That approach can still be specified as a profile on top of the 
existing OCSP specification. The drawback, of course, is that 
compatibility with existing clients would be lost. Note that clients 
can specify the response types they understand via the 
id-pkix-ocsp-response request extension. As OCSP responders are 
required to support the id-pkix-ocsp-basic response type (section 
4.2.1 middle paragraph), conforming responders would have to support 
two different response types. Nevertheless, it seems to me that this 
would be a simple and straightforward solution.

Cheers,
Niklas

On Fri 2019-10-25 at 12:51h, Dr. Pala wrote on pkix:
>interpret correctly (I guess that is why nobody is attaching extra 
>OCSP responses). In fact the text reads:
>
>provide some capability here, but did not provide the use-case for it. 
>- therefore support for "extra" responses is quite interesting. When 
>responses... otherwise, if not locally configured, the responder is 
>not authoritative for other CAs. If your OCSP responder supports 
>multiple CAs and could be authoritative for all of them... which 
>certificate will your responder use to sign the response (i.e., shall 
>it use the certificate that makes it authoritative for the requested 
>certificate or the one that makes it authoritative for the issuing CA 
>status ?)
>
>this complicates the implementation server-side ==> In general, 
>whenever you add the possibility for the client to influence the 
>content of the response, responses need to be generated according to 
>the client-provided parameters, and, therefore, they cannot be 
>pre-computed (which I think can be easily implemented if the number of 
>target responses is sufficiently limited - i.e., your revoked 
>certificates population is small enough that live responders 
>calculate, cache, and update all responses 'live' with great 
>performance and that do not require lots of resources).
>
>Also, would you like to contribute to the effort shall we (IETF) 
>decide to tackle this problem ?
>
>Cheers,
>Max
>
>>allowed to include additional single responses that weren't 
>>explicitly requested by the client, see RFC 6960 section 4.2.2.3 
>>last paragraph.
>>To make the additional responses optional (controlled by the 
>>client), a corresponding request extension could be defined. Hence 
>>that aspect could be covered by specifying a profile of the current 
>>OCSP protocol.
>>
>>Cheers,
>>Niklas
>>
>>
>>>reasons. If I am not mistaken (please correct me if I am wrong), 
>>>the first reason is that the client has to explicitly request the 
>>>requests). The second reason, I think, is related to the trust 
>>>model: the responder have to sign responses from different CAs 
>>>instead of just one - so how can I trust the response from an 
>>>intermediate CA to guarantee me that all CAs above me (me 
>>>included) are not revoked ? It might work if you use a RootCA to 
>>>directly... In addition to that, each certificate carries the 
>>>indication where its revInfo can be retrieved, therefore clients 
>>>tend to make single requests to the different OCSP responders one 
>>>by one (it might be the same, but it might be different). In 
>>>addition to this, there might be implications about pre-computed 
>>>responses
>>>
>>>and attach them together with the response for the request from 
>>>the client. This allows to have different validity period of the 
>>>for the full chain ?" instead of ""What is the Revocation Status 
>>>of Certificate X, Y, and Z ?" - not being sure if this is the 
>>>right responder for all of them)).
>>>
>>>Does that make sense ?
>>>
>>>Cheers,
>>>Max
>>>
>>>

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 26 Oct 2019 11:07:15 +0000

Niklas Matthies <[email-masked]> writes:

>To make the additional responses optional (controlled by the client), a
>corresponding request extension could be defined. Hence that aspect could be
>covered by specifying a profile of the current OCSP protocol.

You could also do a simpler version where the responder includes an extension
that says "I've checked the entire chain from the cert you requested all the
way up to the root.  You're welcome".  It'd be fully compatible with current
deployments, and if clients are able to process the extension they get extra
value from it.

>OCSP responses are allowed to include additional single responses that
>weren't explicitly requested by the client, see RFC 6960 section 4.2.2.3 last
>paragraph.

At one point this was tested and the it was found that the number of
responders/clients who could handle more than one entry per OCSP query and who
hadn't been set up explicitly to work with the Indentrus trust model, which
requires multiple entries, was approximately zero.  So possibly the "I've
verified all the certs up to the root" extension would be easier to get
deployed.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 26 Oct 2019 13:27:23 +0000

Dr. Pala <[email-masked]> writes:

>However, I think there might be some theoretical approach we can also use to
>quantify benefits based on, at a minimum, projected size of the PKI and the
>number of revoked certificates: the lower the revocation ratio is (revoked
>certificates / total valid population), the lower the costs of pre-
>computation for the whole population is.

Right, and you could do that via simulation, or at least calculate, for
various values of X and Y, what the effects would be and at which point you
start to run into problems.  Then, if it looked feasible, you could perhaps
collect from CAs data on what real-world values of X and Y were likely to be.

>It is interesting to notice that this solution makes the costs associated
>with the revocation infrastructure to be directly correlated to the number of
>revoked certificates, instead of the number of issued certificates, thus
>shifting the paradigm quite a bit

Yup.

>In case there is interest, would you like to participate in the effort ?

It sounds interesting, but I don't think I'd have time for it, sorry.

Peter.

---

From: Niklas Matthies <[email-masked]>
Date: Sun, 27 Oct 2019 23:12:30 +0100

On Fri 2019-10-25 at 23:49h, Niklas Matthies wrote on pkix:
[...]
>it would really be simpler and more flexible to just have a linear 
>sequence of regular basic responses. This could be achieved via a new 
>response type (responseType in ResponseBytes) for which the response 
>bytes consist of a sequence of basic responses instead of just one 
>basic response.

Here is an alternative idea, which, although being quite hackish, 
would be compatible with existing clients, would not require a new 
response type, while retaining the same flexibility: In the certs 
field of BasicOCSPResponse, add a dummy certificate carrying an 
extension containing the additional basic responses. That is, the 
certificate's sole purpose would be to serve as a container for the 
additional responses. The extension would have an ID identifying that 
particular purpose.

Note that both proposals have the benefit that they can be implemented 
on top of an existing OCSP responder (i.e. by a filter or proxy), as 
they don't change the data signed by the responder.

Niklas

---

From: Niklas Matthies <[email-masked]>
Date: Sun, 27 Oct 2019 23:12:58 +0100

>deployments, and if clients are able to process the extension they get extra

In my opinion that's highly dubious, as it reverses the chain of 
trust. Even if you trust the responder to have performed that check 
correctly, you first have to validate the responder's signature before 
you can trust the (signed) extension to be authentic, and for that you 
have to validate the responder's certificate chain, which includes the 
CA that issued the certificate being revocation-checked, and hence 
whose validity the extension is supposed to confirm. This effetively 
creates a cyclic dependency of trust.

Suppose that the responder has been compromised (and that it has the 
ocsp-nocheck extension): Then if the CA certificate is revoked due to 
that compromise, a client trusting the extension won't notice, as the 
compromised responder will happily (and falsely) assert that it has 
successfully checked the CA chain.

>>OCSP responses are allowed to include additional single responses 
>>that weren't explicitly requested by the client, see RFC 6960 section 
>>4.2.2.3 last paragraph.
>
>responders/clients who could handle more than one entry per OCSP 
>query and who hadn't been set up explicitly to work with the 
>Indentrus trust model, which requires multiple entries, was 
>approximately zero. 

Having implemented such a client myself, I have to concur. :)

Niklas

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 28 Oct 2019 10:55:54 -0400

I also don't see how this "I've checked the entire chain from the cert 
you requested all the way up to the root.  You're welcome" extension 
would work.

Consider a scenario in which a CA's private key had been compromised, 
and its certificate had been revoked. The attacker, who can use the 
compromised key to issue bogus certificates can not only issue bogus 
end-entity certificates, but also bogus OCSP responder certificates, and 
the bogus certificates can refer to the attacker's OCSP responder as the 
source for status information. The attacker's OCSP responder will 
"helpfully" says "I've checked the entire chain from the cert you 
requested all the way up to the root.  You're welcome." in order to 
encourage me not to directly check the status of the intermediate 
certificates.

The attacker's OCSP responder will tell me that the entire chain is 
okay, but the root CA would have told me that the CA certificate it 
issued has been revoked.

+-----------------------+
|                       |
|        Root CA        |
|                       |
+-----------------------+
             |
             |
            \/
+-----------------------------------------+
|          |
|    Compromised CA         |
|                                         |
+-----------------------------------------+
|                          |
             | certificates issued      |
            \/    by attacker           \/
+-----------------------+ +-----------------------+
|                       | |                       |
|    Bogus certificate  | |    Attacker's OCSP    |
|                       |    |     responder |
+-----------------------+ +-----------------------+

On 10/27/19 6:12 PM, Niklas Matthies wrote:
>>> that weren't explicitly requested by the client, see RFC 6960 
>>> section 4.2.2.3 last paragraph.
>>
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpkix&amp;data=02%7C01%7Cdavid.cooper%40nist.gov%7C2fb50645c09a42b2aa8008d75b2ae66d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637078112122458384&amp;sdata=BmfMVlkZJtYAzOByzxCk5aa6aXFCWOJDxUIVXxxM9vQ%3D&amp;reserved=0 
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 28 Oct 2019 11:17:33 -0400

Actually, this the is widely used, but
not in the way you are suggesting. The use case for the text below
is included in the quoted text: "to improve response
pre-generation performance or cache efficiency."

Take as an example the CA that issued
my PIV Authentication certificate. If I query the CA's OCSP
responder about the status of my certificate I get back an OCSP
response that includes status information for 20 certificates
issued by that CA: my certificate and 19 others. According to the
"Produced At" time in the response, the response was generated
about 45 minutes before I sent my request.

This suggests that the OCSP responder
is serving pre-generated responses, and in order to speed up the
pre-generation of responses, it is generating one response for
every 20 certificates rather than one for every certificate.

The extra OCSP responses are not
providing information about other certificates that I want to know
the status of, they are providing information about other
certificates that I most likely don't care about. My client just
needs to know that the OCSP response may contain additional
SingleResponse elements so that it knows to ignore them and to
check every SingleResponse element to see if any of them covers
the certificate that was asked about.

On 10/25/19 2:51 PM, Dr. Pala wrote:

Hi Niklas,

thanks for pointing that out - that paragraph is quite
difficult to interpret correctly (I guess that is why nobody is
attaching extra OCSP responses). In fact the text reads:

and it starts with a SHOULD NOT :D I guess this was an attempt
to provide some capability here, but did not provide the
use-case for it. - therefore support for "extra" responses is
quite interesting. When reading this paragraph, my first
reaction as a developer is NOT to implement that feature.

Also, if you think about it, there is a Trust problem - why
shall I trust this CA's responder to provide responses up in the
chain ?

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 31 Oct 2019 02:38:05 +0000

Niklas Matthies <[email-masked]> writes:

>In my opinion that's highly dubious, as it reverses the chain of trust. Even
>if you trust the responder to have performed that check correctly, you first
>have to validate the responder's signature before you can trust the (signed)
>extension to be authentic, [...]

Given that the current near-universal use [0] is to trust a replayed, stale
response, typically applying only to the leaf cert, and frequently not even
from the OCSP responder but from an unrelated third party (RFC 6066), this is
a considerable improvement on the current state of practice.

>Suppose that the responder has been compromised (and that it has the ocsp-
>nocheck extension): Then if the CA certificate is revoked due to that
>compromise, a client trusting the extension won't notice, as the compromised
>responder will happily (and falsely) assert that it has successfully checked
>the CA chain.

That's not any worse than the current situation, where the CA cert isn't
checked at all (unless the third-party server implements RFC 6961 and replays
stale responses for the CA certs as well as stale responses for its own cert)
[0 again].  And that's the worst-case situation, for anything other than
worst-case it's an improvement.

Peter.

[0] By this I mean use in HTTPS, and I realise I'm now making the same flawed
    case that I've pointed out numerous times on the TLS WG list, assuming
    that the entire world is the web, but for OCSP this is the near-universal
    use.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 31 Oct 2019 02:44:44 +0000

David A. Cooper <david.cooper=[email-masked]> writes:

>I also don't see how this "I've checked the entire chain from the cert you
>requested all the way up to the root.  You're welcome" extension would work.

See my previous message, it's not meant to be perfect, just an improvement on
current usage.  In particular:

>Consider a scenario in which a CA's private key had been compromised, and its
>certificate had been revoked.

In that case the browser vendors [0 again, from the previous message] push out
an emergency update because they don't trust revocation checking to get the
job done.

So it really depends on the usage scenario.  If you can make it better than
the current mess, that's at least some progress.

Peter.