Subject: [lamps] The Status of OCSP and its future

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Oct 2019 09:01:12 -0600

Hi All,

I just wanted to start the conversation around the status of revocation 
infrastructures and possible work we can be doing to address some of new 
issues deriving from the deployment of large PKIs. In particular, we are 
working on the optimization of the OCSP protocol to better serve some of 
the use-cases we have.

Specifically, 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 is.

Our approach stem from two practical considerations: the occasion to 
provide optimized responses for the non-revoked case, and the 
possibility to reduce the number of round trips required to retrieve the 
revocation status for the full chain of certificates. In particular:

  * /*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 start the 
discussion around the current status of OCSP and possibly work on a 
proposal for moving forward with a more efficient protocol.

What do you think ? Anybody would like to tackle this problem together ?

Cheers,
Max

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

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 24 Oct 2019 11:37:33 -0400

On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[email-masked]> wrote:

> Specifically, 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 is.
>
> provide optimized responses for the non-revoked case, and the possibility
> to reduce the number of round trips required to retrieve the revocation
> status for the full chain of certificates.
>
Don't CRLs address this use case?

That is, it's not clear "Why OCSP" vs "Why not something else" in your
overall message here.

> In particular:
>
>    - *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
>
> On a conceptual level, how is the concept of "Signed status information
for a range of certificates" functionally or conceptually different than a
CRL, potentially sharded (e.g. by varying the issuerDistributionPoint
extension within the CRL and the crlDistributionPoint within the range of
certificates).

As best I can tell, the only difference is that it allows the CA to
rebalance the ranges post-issuance, but it's unclear if that's either good
or desirable from a validator perspective.

>
>    - *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.
>
> Similarly, this is unclear the set of problems you're trying to solve. Did
you mean to provide status information about the full chain? Or did you
actually meant the full chain?

Clients already presumably have the full chain, as they're using OCSP in
the context of RFC 5280 path validation. If the goal is to be able to use
this within protocols that make OCSP available (e.g. TLS), then you already
have the means to deliver the additional certificates.

So I'm not sure how to interpret this suggestion here, and/or why OCSP is
somehow the appropriate technology for it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Oct 2019 12:11:41 -0400

On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[email-masked]> wrote:

> deployed, today, for the IoT case - we would like to start the discussion
> around the current status of OCSP and possibly work on a proposal for
> moving forward with a more efficient protocol.
>
I am interested in the problem. I just disagree with the notion that
X.509/PKIX is a useful way to think about IoT devices. It is not what the
architecture was originally designed to serve and it doesn't actually serve
it at all well.

The reason we need revocation in the WebPKI is that the primary concern
that infrastructure was originally designed to address was the appearance
of fake Web Merchants. The design brief was to make online commerce as safe
as bricks and mortar. The fundamental concern VeriSign Class 3 was designed
to meet was to establish accountability so that posing as a fake Web
merchant was unprofitable. And that limited goal was achieved with enormous
success. Or at least it was before big tech thought it a good idea to strip
out the security signal from the browsers.

The problem with the WebPKI is that it does not serve every purpose well.
And it has been co-opted to a rather sordid dispute into who can invade
users privacy to bombard them with ads and who can't. So we have the
current Congressional hearings and the looming anti-Trust lawsuits. People
who thought PKIX would be so much better without the lawyers and were happy
to see them disappear are going to be in for a nasty shock in the next
couple of years.

We are long past the point where it is prudent for any of the Web Browser
providers with more than 5% market share to allow any of their employees to
contribute to discussions on the WebPKI without having every email vetted
by company lawyers and company lawyers attend every meeting.

The question to ask is why we need revocation at all. In the WebPKI it is
because:

1) Private keys are weakly bound to the devices and are prone to disclosure.
2) WebPKI certificates conflate authentication and authorization and it is
necessary to revoke certificates that are being used by criminals to steal
money.

Neither of these need be a concern in the IoT space. But certificate expiry
and revocation are deeply bound into the architecture. If you decide
neither is needed, you can greatly simplify the architecture: Bind a
keypair into the device during manufacture so that it can never be
extracted without serious effort and 99% of the causes of key compromise
disappear. Separate authentication and authorization and there is no need
for the PKI to be concerned with it.

This is of course the approach I have taken in the Mesh (Singapore, Friday
10:00am). But before people accuse me of using this to promote my own work,
it was this exact set of concerns that led me to design the Mesh in the
first place.

And yes, we can't trust keys that come from a manufacturer and nor do I
suggest that we ever should. PKIX was designed according to the
cryptographic capabilities as they were understood in 1978 when Kohnfelder
wrote his master's thesis. We have moved on since. The techniques I am
applying were invented in the 1990s but since people are loathe to
recognize technology unless it is all bright and shiny, I have re-branded
them 'meta-cryptography'.

Point is that today we face a number of concerns that were almost entirely
theoretical or limited to the most sensitive applications in the 1990s:

* Alice used to share her computer with more than 50 other students, now
she owns more than 50 computers. The key provisioning problem has changed
completely as a result.

* Compromise in the supply chain is no longer a theoretical problem, nor is
the problem a single state actor as some suggest. The supply chains are
large, complex and opaque. Nobody really knows the provenance of anything
unless it is one of the handful of devices from a trustworthy foundry.

* The shortest password that is secure is far longer than the longest
password that is memorable and this cannot be solved by changing the hash
function. The capabilities of massively parallel machines outstrips the
capacity of a single core by many orders of magnitude. There is no
technical means of making exhaustive search prohibitive.

* We are no longer just providing security to government employees,
academics and students. We can't expect them to adapt to our technologies
any more. *Don't try to change the user*.

* The Internet has 5 billion users and 50 billion devices. Deployment of
technology is a vastly harder challenge than designing or implementing it.
We have to design for deployment and we cannot do that with a design from
the 1970s.

This does not mean that PKIX is irrelevant, far from it. What I have done
in the Mesh is to take the use patterns that emerged from the deployment
and use of PKIX and reified them as architecture. So Alice can now use
online/offline key management to protect her data but don't tell Alice that
because she doesn't need to know thats what she is doing.

To paraphrase Keynes: We have unused cryptography in a world of security
need.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Oct 2019 15:10:59 -0400

Dr. Pala <[email-masked]> wrote:
    > 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 is.

Why not just spread your load across multiple OCSP endpoints by putting
different AuthorityInfoAccess values in?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 25 Oct 2019 08:52:21 +0200

> revocation infrastructure is.

As there are many PKIs today with 100M+ entities, some with and some
without revocation infrastructure, I think it's a bit too broad claim
for all use cases.
It is certainly true of all operations, the larger the scale the larger
infrastructure costs usually are, where OCSP I'd say is generally a very
minor part.
It differs from use case to use case though, I think it would be good
for the discussion to provide more details on your problematic use case,
architecture, use pattern etc. Many things are use case and
implementation choice specific.

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

What could a "range" of certificates be based on?
(I consider sequential serialnumbers to be dead by now)

>     is used, but it would definitely work for the Web PKI and IoT use cases.

If extra round-tripping is needed it is certainly a concern. This is
also valid and discussed in the Web PKI case.

> proposal for moving forward with a more efficient protocol.

We do se working use cases with OCSP for huge number of devices, but in
IoT it's all use case dependent so I'm interested in more on your use case.

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 25 Oct 2019 10:14:49 +0300

Dear Tomas,

> (I consider sequential serialnumbers to be dead by now)

E.g. notBefore time?

-- 
SY, Dmitry Belyavsky

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 25 Oct 2019 09:53:14 +0200

On 2019-10-25 09:14, Dmitry Belyavsky wrote:
> Dear Tomas,
> 
> On Fri, Oct 25, 2019 at 9:58 AM Tomas Gustavsson
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
>     >

That certainly works for partitioning, often used in partitioned CRLs of
course.

---

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

Hi Tomas,

On 10/25/19 12:52 AM, Tomas Gustavsson wrote:
>> [...]

This is a good point - very practical approach. A sample use-case is our 
industry (Cable). In particular, in our industry, we leverage PKIs to 
secure the communication in our networks: each Cable Modem and DVRs come 
with one or more certificates from our infrastructure. This covers all 
modems from all vendors from all operators.

Our Network, though, are going through radical changes that are aimed at 
providing the 10Gig platform we just released the standard for. In 
particular, the new architectures will see an increasing number of 
"entities" that require authentication.

As you can see, our PKI tend to be larger than what you typically see in 
the Web PKI (quite small in comparison - even combining all providers), 
therefore improving the efficiency and reducing the costs is a big win 
for the industry in general and for the users since we can now provide 
OCSP responses with shorter validity periods, thus reducing the risk 
level of our Access Networks.

This is not the only use-case, though.

Many IoT environments are starting to use digital certificates for 
authentication at a scale. Some environments, like the Power Grid, are 
already deploying solutions that use certificates to protect the 
communication up to the customers' premises.

Another use-case that I am bringing forward is Cellular. In particular, 
we already have standardized the use of certificates in some 
environments (e.g., CBRS-A, 5G Fixed, etc.) and it is expected that by 
freeing the network authentication from the need of a physical SIM (and 
associated licensing costs) we will see more and more devices (e.g., Fix 
and Industrial) using this technology.

This said, I think that reducing the costs of providing revocation 
information is a good goal in general and can help reducing 
authentication risks by providing shorter validity responses.

>> [...]

Our current approach is very simple. Take a CRL and produce (a) one 
response for each revoked certificate, and (b) one response for each 
range between revoked serial numbers. For example, if you have the 
following serial numbers revoked { 3, 5, 12 }, then you would sign 3 
responses for the 3 revoked certificates, plus the response from "0" to 
"3", two responses for the gaps between {3 and 5} and {5 and 12}, plus 
the last response for 5+. In this case, the number of revoked 
certificates is 3 and the number of signed responses is 2N + 1 = { 3 
revoked } + { 1 from 0 to the first entry } + { 2 gaps } + { 1 from last 
to infinity } = 7

Therefore, with this approach, if you are good at keeping the number of 
revoked certificates low, you can see how efficient this technique can 
be - especially when you revoked/valid certificate ratio is very low.

> also valid and discussed in the Web PKI case.
It is to be mentioned that providing the full chain is possible today - 
however, no clients I know leverages this option. This, I think, it is 
because of several factors (i.e., trust model, AIA in certificates, 
etc.) that, if you are interested, we can explore separately.
> IoT it's all use case dependent so I'm interested in more on your use case.

I hope that I provided you with some compelling scenarios here - I think 
that by optimizing the provisioning of revocation information we can 
help not only our specific use cases, but also the deployment of 
revocation information infrastructures that are low-cost for 
environments where using CDNs, Load Balancers, etc. is not an option 
because of the cost :D

Thanks for the reply - I do really appreciate the feedback!

Cheers,
Max

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

---

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

Hi Michael,

> different AuthorityInfoAccess values in?

thanks for the comment - yes, I think that is an option. However, that 
does add complexity to the issuing system that might need to be tweaked 
as the infrastructure grows... and that does not lower my operational 
costs that can be significant for large PKI environments.

The proposal here is to optimize for the average case (and maybe 
simplify the messages in the process) - in particular providing 
responses for ranges of certificates (serial) where there is no 
revocation information available.

Although this is quite relevant for the Industry I work in (Cable), 
optimizing revocation information distribution might lower the 
operational cost for every PKI that implements revocation - the WebPKI 
included. In particular, if such a solution existed, then we could see 
OCSP responses for the WebPKI that have shorter validity periods, I 
think and hope: hours instead of days or months.

Thanks again for the feedback!

Cheers,
Max

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Oct 2019 10:48:27 -0400

> "entities" that require authentication.
Knowing that it is all hilariously insecure, I have deployed roughly
$20,000 worth of smarthome type equipment in my house so as to experience
it myself.

At this point, it is very clear to me that this stuff is really not suited
for anyone who is not an enthusiast. IoT is a hobby and it is going to
remain so unless we see some major improvements in manageability.

I currently have about 100 devices of which 50 have IP addresses. So
multiply by a billion or so households and that is a heck of a lot more
devices than we have been thinking about to date.

If we are going to get a handle on this, we have to change the
architecture. I don't think there was ever a business or such with 50
devices that would put itself on the internet without some sort of
co-ordination service on site. And to get to 100 there would be redundancy
and such.
Yes, peer to peer looks cool until you get to the point where n^2 is a big
number and then it is a headache. Peer to peer means that I have to
maintain each of my printers on every machine in the house. Just does not
scale.

The Cable Modem and DVR are the natural devices for such co-ordinating
services to reside.

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 25 Oct 2019 09:18:13 -0600

Hi Ryan,

On 10/24/19 9:37 AM, Ryan Sleevi wrote:
>
>
> On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi All,
>
>     I just wanted to start the conversation around the status of
>     revocation infrastructures and possible work we can be doing to
>     address some of new issues deriving [...]Our approach stem from
>     two practical considerations: the occasion to provide optimized
>     responses for the non-revoked case, and the possibility to reduce
>     the number of round trips required to retrieve the revocation
Yes and No. "Yes" because CRLs provide the same type of information - 
you are correct :D "No" because CRLs provide all the information at once 
- the reason we have OCSP today is to address the "Large CRLs" problem.
> That is, it's not clear "Why OCSP" vs "Why not something else" in your 

Well, I do not want to exclude the possibility to work on "something 
else" :D

Our proposal is to provide a more efficient way to deliver the service 
that can still be used with current protocols (e.g., OCSP stapling) - 
this addresses the medium-term deployment and, we believe, provide an 
additional tool for the PKI architects when planning / designing the 
revocation infrastructure for their PKIs.

If there are other proposals on the table for improving efficiency, it 
would be great to hear them - this can spark an healthy discussion 
around handling revocation in PKIX (maybe a dedicated WG if LAMPS is not 
the right place... ?) :D However, until then, our proposal is to work on 
something rather than not do anything :D

>     [ ...]
>
> On a conceptual level, how is the concept of "Signed status 
> information for a range of certificates" functionally or conceptually 
> different than a CRL, potentially sharded (e.g. by varying the 
> issuerDistributionPoint extension within the CRL and the 
> crlDistributionPoint within the range of certificates).
>
> rebalance the ranges post-issuance, but it's unclear if that's either 
> good or desirable from a validator perspective.
I think you got it right :D The main difference is that the 
issuerDistributionPoint is a static assignment and that might not be 
optimal. As you point out, it is a possibility today to do this, however 
there is no guarantee for the client that the target CRLs will not be 
big in size (since it is a static assignment, that is an unknown). 
Therefore, to provide the same level of flexibility, you might need to 
plan for thousands or even millions of different endpoints for a single 
CA. Conceptually, not a big issue. From a DevOps perspective... very 
scary, IMHO.
> [...]
>
> Similarly, this is unclear the set of problems you're trying to solve. 
> Did you mean to provide status information about the full chain? Or 
> did you actually meant the full chain?
>
> Clients already presumably have the full chain, as they're using OCSP 
> in the context of RFC 5280 path validation. If the goal is to be able 
> to use this within protocols that make OCSP available (e.g. TLS), then 
> you already have the means to deliver the additional certificates.
>
> So I'm not sure how to interpret this suggestion here, and/or why OCSP 
> is somehow the appropriate technology for it.
Sorry for the lack of clarity here - I meant providing the revocation 
information for the full chain, not the full chain itself :D In 
particular, although this is possible with today's protocol, it is a 
feature that is not used by clients. There might be several 
considerations as to why this is (my personal point of view is because 
of a series of different practical reasons - trust model, AIA in 
certificates, how path-building and validation is approached by crypto 
libraries).

As discussed before, there might be some other technologies for this - 
our proposal is to provide an updated version of the OCSP that optimizes 
responses for the non-revoked case and lowers the operational 
requirements and costs associated with it.

Does this address your questions ? Would you be interested in 
participating to the work ?

Cheers,
Max

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

---

From: "Dr. Pala" <[email-masked]>
Date: Fri, 25 Oct 2019 09:38:03 -0600

Hi Phillip, All,

thanks for the reply - lots of interesting considerations. Please 
forgive me if I am not familiar with the details around your proposal 
(Mesh), however I think it is a good idea to work in the space - as you 
say, although the approach might be different, the problem is actually 
the same.

 From what you write, it seems that your approach is more "radical" and 
try to tackle the problem for a specific angle - the security of keys. I 
do not see this to be a competitor solution, but more as a comprehensive 
approach. In this vision, the two solutions might also have different 
time horizons: shorter for the OCSP optimization and longer for more 
comprehensive changes.

This said, I would like to re-focus the conversation on the proposed 
idea and ask you if you see any issue related to the proposal itself. 
Without more text and an I-D it is difficult to have a clear vision 
around it, but at least the core idea is there :D

Also, in case we do move forward, would you like to participate in the 
effort ?

Cheers,
Max

On 10/24/19 10:11 AM, Phillip Hallam-Baker wrote:
>     Given these considerations - and the fact that large PKIs are
>     being deployed, today, for the IoT case - we would like to start
>     the discussion around the current status of OCSP and possibly work
>     on a proposal for moving forward with a more efficient protocol.
>
> X.509/PKIX is a useful way to think about IoT devices. It is not what 
> the architecture was originally designed to serve and it doesn't 
> actually serve it at all well.
>
> The reason we need revocation in the WebPKI is that the primary 
> concern that infrastructure was originally designed to address was the 
> appearance of fake Web Merchants. The design brief was to make online 
> commerce as safe as bricks and mortar. The fundamental concern 
> VeriSign Class 3 was designed to meet was to establish accountability 
> so that posing as a fake Web merchant was unprofitable. And that 
> limited goal was achieved with enormous success. Or at least it was 
> before big tech thought it a good idea to strip out the security 
> signal from the browsers.
>
> The problem with the WebPKI is that it does not serve every purpose 
> well. And it has been co-opted to a rather sordid dispute into who can 
> invade users privacy to bombard them with ads and who can't. So we 
> have the current Congressional hearings and the looming anti-Trust 
> lawsuits. People who thought PKIX would be so much better without the 
> lawyers and were happy to see them disappear are going to be in for a 
> nasty shock in the next couple of years.
>
> We are long past the point where it is prudent for any of the Web 
> Browser providers with more than 5% market share to allow any of their 
> employees to contribute to discussions on the WebPKI without having 
> every email vetted by company lawyers and company lawyers attend every 
> meeting.
>
>
> The question to ask is why we need revocation at all. In the WebPKI it 
> is because:
>
> 2) WebPKI certificates conflate authentication and authorization and 
> it is necessary to revoke certificates that are being used by 
> criminals to steal money.
>
> Neither of these need be a concern in the IoT space. But certificate 
> expiry and revocation are deeply bound into the architecture. If you 
> decide neither is needed, you can greatly simplify the architecture: 
> Bind a keypair into the device during manufacture so that it can never 
> be extracted without serious effort and 99% of the causes of key 
> compromise disappear. Separate authentication and authorization and 
> there is no need for the PKI to be concerned with it.
>
> This is of course the approach I have taken in the Mesh (Singapore, 
> Friday 10:00am). But before people accuse me of using this to promote 
> my own work, it was this exact set of concerns that led me to design 
> the Mesh in the first place.
>
> And yes, we can't trust keys that come from a manufacturer and nor do 
> I suggest that we ever should. PKIX was designed according to the 
> cryptographic capabilities as they were understood in 1978 when 
> Kohnfelder wrote his master's thesis. We have moved on since. The 
> techniques I am applying were invented in the 1990s but since people 
> are loathe to recognize technology unless it is all bright and shiny, 
> I have re-branded them 'meta-cryptography'.
>
> Point is that today we face a number of concerns that were almost 
> entirely theoretical or limited to the most sensitive applications in 
> the 1990s:
>
> * Alice used to share her computer with more than 50 other students, 
> now she owns more than 50 computers. The key provisioning problem has 
> changed completely as a result.
>
> * Compromise in the supply chain is no longer a theoretical problem, 
> nor is the problem a single state actor as some suggest. The supply 
> chains are large, complex and opaque. Nobody really knows the 
> provenance of anything unless it is one of the handful of devices from 
> a trustworthy foundry.
>
> password that is memorable and this cannot be solved by changing the 
> hash function. The capabilities of massively parallel machines 
> outstrips the capacity of a single core by many orders of magnitude. 
> There is no technical means of making exhaustive search prohibitive.
>
> academics and students. We can't expect them to adapt to our 
> technologies any more. _*Don't try to change the user*_.
>
> * The Internet has 5 billion users and 50 billion devices. Deployment 
> of technology is a vastly harder challenge than designing or 
> implementing it. We have to design for deployment and we cannot do 
> that with a design from the 1970s.
>
> This does not mean that PKIX is irrelevant, far from it. What I have 
> done in the Mesh is to take the use patterns that emerged from the 
> deployment and use of PKIX and reified them as architecture. So Alice 
> can now use online/offline key management to protect her data but 
> don't tell Alice that because she doesn't need to know thats what she 
> is doing.
>
>
> To paraphrase Keynes: We have unused cryptography in a world of 
> security need.
>
-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 25 Oct 2019 11:50:57 -0400

On Fri, Oct 25, 2019 at 11:18 AM Dr. Pala <[email-masked]> wrote:

> there is no guarantee for the client that the target CRLs will not be big
> in size (since it is a static assignment, that is an unknown). Therefore,
> to provide the same level of flexibility, you might need to plan for
> thousands or even millions of different endpoints for a single CA.
> Conceptually, not a big issue. From a DevOps perspective... very scary,
> IMHO.
>

I suppose I'm still not sure I fully understand your concerns here.

That is, it seems like as an operational consideration, the balancing of
the issuerDistributionPoint allows you to bound your worst-case
performance, while making suitable tradeoffs for your average and best case
scenarios. As others have suggested, it seems like more work would be
needed to show the math as to why this is a problem, given the rather
extensive flexibility already afforded to address this using existing
technologies.

> As discussed before, there might be some other technologies for this - our
> proposal is to provide an updated version of the OCSP that optimizes
> responses for the non-revoked case and lowers the operational requirements
> and costs associated with it.
>

As others have suggested (e.g. in PKIX), I think that it'd be far more
useful to not suggest it's a "OCSPv2" and instead highlight that you're
interested in providing an alternative revocation protocol, one that
seemingly combines elements of SCVP with the design of underlying protocols
like TLS.

> participating to the work ?

I have no interest in this work. I think that, for the problem described,
it would be incompatible and undesirable for the PKIs I work with (that is,
the Web PKI used by Chrome).

That doesn't preclude there being value in exploring this for other PKIs;
my only interest would be in trying to effectively communicate the lack of
interest to avoid overfit for an implementation that won't adopt :)

To echo other's remarks, I think an improved approach that clearly
communicated the problem statement, and the comparison with the existing
technologies and operational capabilities, would be very useful in helping
others determine the relevance to their PKIs and/or products. From both
this and the PKIX thread, I do feel I've got sufficient information to say
"Not interested", but it took me quite a bit of confusion to get there ;)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 25 Oct 2019 12:55:00 -0400

Returning to the original point, yes, there is indeed a problem with the
scalability of issuerDistributionPoints as we discovered when we visited
this whole discussion in 1998.

At the time we had a whole set of IPR issues covering a patent claim as
well. I don't recall whether it got anywhere but I suggested a mechanism
which avoids the scaling issue.

The problem with distribution points is that the partition of the
certificate space has to be decided in advance. Which forces the issuers to
be conservative in their partitioning. Worse, you are then obliged to
maintain separate CRLs for each partition whether you want to or not.

This is avoided by the introduction of a scope extension in the CRLs
specifying that it applies to a range of certificate serial numbers. This
means that if there are 500 revoked certs, the issuer can issue five CRLs
with 100 each. And then if the number increases to 750, they can increase
to 8 CRLs each of which is less than a hundred.

There are other schemes that can be used. It is actually possible to
compress CRLs even when the serial numbers are random numbers, Rob
Straddling and myself made some proposals in that area which I will
probably adopt at some point in the Mesh.

To respond to the specific points:

On Fri, Oct 25, 2019 at 11:38 AM Dr. Pala <[email-masked]> wrote:

> Hi Phillip, All,
>
> thanks for the reply - lots of interesting considerations. Please forgive
> me if I am not familiar with the details around your proposal (Mesh),
> however I think it is a good idea to work in the space - as you say,
> although the approach might be different, the problem is actually the same.
>
> From what you write, it seems that your approach is more "radical" and try
> to tackle the problem for a specific angle - the security of keys. I do not
> see this to be a competitor solution, but more as a comprehensive approach.
> In this vision, the two solutions might also have different time horizons:
> shorter for the OCSP optimization and longer for more comprehensive changes.
>
There is a BOF in Singapore on Friday. I am currently working with people
to get the Web site put in order.
http://mathmesh.com/

There is a video series presenting the technical approach, the first parts
of which are available here:
https://www.youtube.com/playlist?list=PLK2hHAOxepEgGUx4SitfD4pIPHi86KHpi

These will be available as a download for people who are looking for some
in-flight entertainment for the flights to/from Singapore.

We also have some Internet drafts of which about 6 are reasonably complete
at this point (but not final of course).

This said, I would like to re-focus the conversation on the proposed idea
> and ask you if you see any issue related to the proposal itself. Without
> more text and an I-D it is difficult to have a clear vision around it, but
> at least the core idea is there :D
>
Yes, I am interested in both. There might even be existing (but long
expired!) drafts.

I don't necessarily think the Mesh is in competition with or irrelevant to
PKIX. It might well be that what we end up doing is deciding that we want
to take advantage of the technology but want it in an ASN.1 idiom. That is
certainly possible but would obviously be a lot more design effort as one
of the reasons I was able to develop the Mesh in such a short time with
limited resources was that I ignored legacy constraints.

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 29 Oct 2019 21:34:10 +0700

Hi Max,

> and Industrial) using this technology.

These are all good examples of where PKI is used. Perhaps I am too eager
to quickly dive into technical details :-). What I was looking for was
some sort of calculations in the cost today using current technologies,
and the possible gains.

For example, (a very speculative one so please forgive my ignorance. I
am quite familiar with telecom and smart metering, but not with cable
modems):
- 100M set top boxes
- 100 media servers
Each set top box talks to media servers, load balanced.
Mutual TLS authentication, and revocation checks on all certificates
OCPS response lifetime 24h
Certificate lifetime of 1 year, renewal after 7 months

We will have somewhere around 150M certificates active. Servers can use
OCSP stapling, hence only 100 OCSP requests per day.
Each server may have contact with all set top boxes during an evening,
so each server has to make 150M OCSP requests per day. Servers cache
responses and don't make the same request twice if it already have a
fresh response. Everyone start their set top box during a two hour
window in the evening, so 150M*100/7200 OCSP requests must be handled
per second during this two hour window (it's almost 2M/second). Is this
something that you are thinking about where OCSP does not scale enough?

It is more about being able to respond quickly enough than to provision
the revocation information to OCSP responders though, so I'm not sure I
got the problem picture clear still.

> be - especially when you revoked/valid certificate ratio is very low.

I think relying on sequential serialnumbers to be a big risk. It assumes
a lot of the PKI implementation, which may not be true. It is certainly
not true for the Web PKI, and also not for the IoT, Enterprise and smart
grid deployments we have been involved with. Any standard should not
rely on such PKI implementation details.