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

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> 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
>
> Also, in case we do move forward, would you like to participate in the
> effort ?
>
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.