<HTML><HEAD></HEAD>
<BODY dir=ltr>
<DIV dir=ltr>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>All,</DIV>
<DIV> </DIV>
<DIV>Getting back to the problem of certificate issue I see the following
options on the table:</DIV>
<DIV> </DIV>
<DIV>1) CRL Sets</DIV>
<DIV>2) OCSP stapling + must stapled</DIV>
<DIV>3) Short lived certificates (48 hour validity)</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>[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.]</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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:</DIV>
<DIV> </DIV>
<DIV><A title=http://tools.ietf.org/html/draft-hallambaker-omnipublish-00
href="http://tools.ietf.org/html/draft-hallambaker-omnipublish-00">http://tools.ietf.org/html/draft-hallambaker-omnipublish-00</A></DIV>
<DIV> </DIV>
<DIV>I am looking for supporters, reviewers etc. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>The draft is a simple JSON-REST based service for establishing a network
service. This means</DIV>
<DIV> </DIV>
<DIV>1) Acquiring the necessary credentials</DIV>
<DIV>2) Requesting necessary firewall configuration, DNS config etc.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV><A title=http://tools.ietf.org/html/draft-hallambaker-wsconnect-08
href="http://tools.ietf.org/html/draft-hallambaker-wsconnect-08">http://tools.ietf.org/html/draft-hallambaker-wsconnect-08</A></DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></DIV></BODY></HTML>