Re: [pkix] Compressed CRLs

Comments inline.

On 10/16/14, 7:17 AM, Erwann Abalea 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?
>
AAAArrgghhh!! Each time I ear about CRLSet I get goose bumps - that is 
an abomination that completely breaks PKIX revocation by simply ignoring 
the authoritative source of information and it is a single-vendor 
(wrong) solution to revocation checking :(

Regarding the idea at hand, it is interesting from a theoretical point 
of view, but I do not think it does introduces benefits over simple 
OCSP, OCSP stapling (or OCSP over DNS) - at the same time it does not 
support all revocation cases we need in PKIX. By reading the document, I 
think that the big issue here is that this mechanism seems to ignore 
(but correct me if I am wrong) that revocation is not just "revoked" or 
"not revoked" but it carries along additional information (i.e. reason 
for revoking). Moreover, the "pending IPR issue" and the corresponding 
"licensing" model is a big issue and a legal nightmare that nobody would 
be happy to deal with, IMHO.

For these reasons, I do not think that this is a work that should be 
addresses in its current form within the IETF.

Cheers,
Max

> 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).
>
>
> 2014-10-09 14:55 GMT+02:00 Phillip Hallam-Baker <phill@hallambaker.com 
> <mailto:phill@hallambaker.com>>:
>
>     I sent this to TLS in the first instance but it might be of more
>     interest here. It turns out that we can compress CRLs much better than
>     anyone imagined. Using compression we can issue a CRL for every
>     unexpired SSL Server cert  using less than the 250K that is the limit
>     on Google's curated CRLSet.
>
>
>     Please note:
>
>     http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/
>     Also note the pending IPR disclosure.
>
>     In brief Rob Stradling and myself have come up with a radically new
>     approach to certificate status that is vastly more efficient than any
>     previous proposal that provides finer grain certificate status than
>     the certificate validity interval.
>
>     While compressing hash tables might appear to be a fools errand, it
>     turns out that if the problem is correctly understood, CRLs actually
>     compress astonishingly well. It is actually possible to represent the
>     status of every one of the half million revoked certificates in the
>     WebPKI using fewer bytes than the heavily edited Google CRLSet.
>
>     There is still a powerful case for short lived certificates. But the
>     minimum feasible expiry interval for short lived certs is 48 hours.
>     Using a compressed CRL in combination with short lived certs would
>     allow the vulnerability window to be reduced to minutes.
>
>
>     We are of course aware that deployment will require a licensing regime
>     that meets the need of all parties including competing CAs, open
>     source software providers, etc. However lacking an existing licensing
>     regime for the rights holder (if indeed any are granted), I thought it
>     best to bring this to people's attention first.
>
>     The nature of the invention is such that not applying for a paten;t
>     would open the possibility that someone else might make a claim as has
>     happened to me on numerous other occasions. In the past five years
>     over $50 million has been spent on defending against such patent
>     claims.
>
>     _______________________________________________
>     pkix mailing list
>     pkix@ietf.org <mailto:pkix@ietf.org>
>     https://www.ietf.org/mailman/listinfo/pkix
>
>
>
>
> -- 
> Erwann.
>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix