[cabfpub] Revocation and Certificate Issue

[Phillip Hallam-Baker]

All,

Getting back to the problem of certificate issue I see the following options on the table:

1) CRL Sets
2) OCSP stapling + must stapled
3) Short lived certificates (48 hour validity)

Of these, only 1 and 2 are feasible with current technology and (1) does not solve the problem as far as CAs are concerned (and I don’t want to talk about that subject right now). And even if they did work the revocation set still scales in proportion to total certificates issued and so its not a long term solution.

[BTW: Yes, I have pinged on the Must staple draft request again over the weekend though if someone else wants to take over the chasing thing then maybe they are better at getting results than me.]

I also note that (2) has the same imposition on the server as a short lived cert. After all, an OCSP token is kindof like a short lived cert. Which means that in my view any long term solution to revocation has to be based on short lived certs for end entity certificates plus a CRLSet for the intermediate certs (which is not a scaling issue as they should never be revoked in normal circumstances).


And so I have been looking at the impediments to deployment of short lived certs. And the main one is that certificate admin is just too much of a hassle at the moment. And so I wrote this draft:

http://tools.ietf.org/html/draft-hallambaker-omnipublish-00

I am looking for supporters, reviewers etc. 


The draft is a simple JSON-REST based service for establishing a network service. This means

1) Acquiring the necessary credentials
2) Requesting necessary firewall configuration, DNS config etc.

I have combined these two functions for several reasons. One is that if the PKIX world was to suggest a new enrollment process that was not DANE friendly right now there would be fightin’ words and a counter proposal. The other is that it just makes total sense to wrap everything up into one service.


The approach described greatly simplifies the whole process of applying for a certificate IF THE SPEC IS SUPPORTED BY THE SERVER. Lets face it, I can write a plug in that makes it really easy to apply for certs from Apache but the pain of installing the plug in and running Apache with it is going to be much greater than the pain of applying for a cert.

As with all my recent work, it builds on the SXS-Connect protocol which is simply a mechanism that allows me to bind the end-entity to use the certificate to the service supplying it.

http://tools.ietf.org/html/draft-hallambaker-wsconnect-08

At the moment the spec only describes use for applying for a PKIX cert using a CSR and I have only tried it for TLS and S/MIME. But it would work equally well for other cert request formats and other types of cert. SAML assertions for example. I think it would work for PGP as well.


The description is centered on the most common SOHO small business applying for cert use case but the scheme is certainly applicable to more complicated schemes with firewalls, in-house local RAs etc. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140602/3aaad04e/attachment-0002.html>