[cabfpub] Revocation and Certificate Issue

[Phillip Hallam-Baker]

Yes, to get a 24 hour validity time you need a minimum window of 24+24+24 = 72 hours. So the certs are valid for 48 hours at issue, postdated 24 hours (plus the start of the previous day in my current code).

The spec is completely neutral as far as validity time is concerned.

I will do whatever is necessary on the draft tomorrow..


From: Jeremy Rowley 
Sent: Monday, June 02, 2014 4:17 PM
To: 'Phillip Hallam-Baker' ; 'CABFPub' 
Subject: RE: [cabfpub] Revocation and Certificate Issue
Hi Phillip, 

 

I think 72 hours is a better validity period for short-lived certs.  Looking at this before, the clock skew was still problematic at 48 hours.  Also, one of the obstacles in promoting short-lived certs is the lack of benefit to the server operator and CA in creating these (under the current BRs).  CAs are still required to publish OCSP information and browsers will still check for revocation (or not) regardless of the certificate validity  Unless there is a better benefit, you won’t likely see much support.  That said, I’m still in favor of short lived certs and will happily review and provide input.

 

Also, I submitted a request to IANA for the must staple OID.  They responded saying I need your approval before the approval is complete.  They also said we’d need to update your draft to include a section on IANA considerations.  I’m happy to help with pushing this along, I just need an email from you approving of OID request.  

 

Thanks!

 

Jeremy 

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Phillip Hallam-Baker
Sent: Monday, June 2, 2014 12:59 PM
To: CABFPub
Subject: [cabfpub] Revocation and Certificate Issue

 

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/5c08c806/attachment-0003.html>