Re: [pkix] Compressed CRLs

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

On Thu, Oct 16, 2014 at 1:17 PM, Erwann Abalea <[e-mail]> wrote:

> Interesting draft. Can be implemented by a third party if and only if it
> has access to all the unexpired certificates (insert GoogleCT here), or by
> the CA itself.
> Will there be more details on the additional optimizations by Rob? Does
> this additional optimization apply to a complete CRLSet or only to deltas?
>

I want to get folk to focus on the specific way they want to use it before
we drill down into exactly how to represent it. If we are doing one big CRL
per day then extra compression makes a lot of sense. If we are doing deltas
we need to look at the total complexity of the scheme.



> Regarding the encoding, my preference goes to ASN.1 over JSON. ASN.1 has a
> native BITSTRING type and several already standardized encoding rules, one
> of them being optimized for space (PER and unaligned PER, X.691). But this
> is only a serialization issue and doesn't conflict with the general idea;
> some don't like ASN.1 (for bad reasons), some don't like PER (for not so
> bad reasons). A good compact and easy encoding may be the recently approved
> OER (X.696).
>

We don't use ASN.1, never have. We use tools that happen to take ASN.1
syntax. And that is a huge difference.

Unless the authors of OpenSSL and NSSAPI etc. tell me their compilers work
just fine with PER than it doesn't exist as far as I am concerned.

We have already broken with ASN.1 in TRANS which does not use ASN.1 for
internal structures. It uses the TLS schema.


As far as my personal code set goes, I can switch from generating ASN.1 to
TLS or JSON at will. (I don't use ASN.1 schema which simplifies a lot.) So
I am not protecting my code here. But in general discussions over encoding
don't have a lot of weight for me unless they begin 'I am the maintainer of
X. widely used code library).