Re: [therightkey] [pkix] Proposal for working on PKIX revocation open issues

[Nico Williams <[e-mail]>]

On Sat, Nov 15, 2014 at 3:56 PM, Phillip Hallam-Baker
<[e-mail]> wrote:
>> (a) Defining new transport protocols for revocation information availability
>> (e.g., OCSP over DNS or OCSP over LDAP)
>
> There is already a mechanism for transporting certs over LDAP. I am
> pretty sure the folk who do that sort of thing have done the OCSP in
> LDAP thing already.
>
> I don't see a future for LDAP as an Internet protocol though. LDAP

Indeed, but it is an Internet protocol that is widely used in the enterprise.

> introduces a completely gratuitous name infrastructure (X.500) that

Eh?!  It's the same [busted, obnoxious, unworkable, <fill-in-curses>]
naming model as PKIX.  RFC4514 is a great demonstration of what a
disaster X.500 naming is, but don't be fooled by the "LDAP" in the
title: it's as good a demo of X.509's disastrous naming.

> adds no value other than to the consultants who can spin a 3 week
> consulting gig bikeshedding the DIT with the customer. Nobody has ever
> explained an advantage to me of LDAP over HTTP and a well-known
> service convention.

LDAP is hardly my favorite protocol.  Its biggest sin is really not
its fault, but the implementors, who have by and large adopted the
LDAP representation of "objects" as their native representation of the
same, losing a lot of relational power in the process.  The other
problem is that LDAP's is a poor query language.

As for HTTP...  HTTP doesn't do what LDAP does.  One could define a
DAP over HTTP (an "API"), and that'd be a fine thing.

>> (c) (Possibly) helping other working groups to revise and update how
>> revocation information are provided (e.g., the client authentication case)
>
> CRLs probably work just fine for servers validating private label client certs.

Yes.

> I have a different set of proposals:
>
> 1) Stapled OCSP with MUST-STAPLE OID
> 2) Short lived Certificates
>   2a) With the same key
>   2b) With different keys
> 3) CRLs with HBS compression.

+1

Nico
--