CAcert Code Development list.

[Iang <iang AT cacert.org>]

Hi,

My view would be as Dirk suggested - take out the reference to 24 months 
entirely.  For completeness, perhaps put in there "Revocation periods 
are subject to a practice document published by Board (aka team leader) 
from time to time."

On 02/02/2021 10:38, Bernhard Fröhlich wrote:
> Hello dear Policy Group,
>
> about half a year ago, bug #1482 
> <http://bugs.cacert.org/view.php?id=1482> has been reported.
>
> Chromium and Apple intend to require from their accepted CAs that they 
> only issue HTTPS certificates with a maximum lifetime of one year. 
> This bug report requests that CAcert should follow this requirement.
> Now, the technical change to implement this is absolutely trivial, but 
> the current CPS explicitly states that certificates for assured 
> members have a lifetime of 24 months, and IMHO it is not legitimate 
> that the software development installs a software change that 
> explicitly contradicts the CPS.
>
> So policy group should discuss and decide whether we want to adopt 
> this requirement (and therefor change the CPS) or not.
>
>
> AFAIK the background of this requirement is the observation that all 
> current revocation procedures have severe shortcomings and are 
> therefore not widely implemented. So a certificate normally can used 
> for its whole lifetime, even if its private key is known to be 
> compromised.


Yes - revocation has always been broken as a concept.  But it was pushed 
as "essential" by CAs primarily because it gave CAs a reason to exist.  
In principle, at a high level, only a third party can easily make a 
revocation claim over some person's credentials.  We need CAs to do 
this, hooray!

But in practice the concept in x.509/PKI was a joke, on many levels.  
Nobody's been able to make revocation work such that it actually 
provides real and measurable protection.  And there are good reasons why 
it will never be so.


> The current strategy to mitigate this situation is obviously to go for 
> shorter certificate lifetimes and automated re-issuing of 
> certificates, like let's encrypt does this.


Right, so their answer is to shorten the issuance period.  But they 
can't shorten it too far, bc eg like 90s days, people will ask, why not 
1 day?  Why not 1 minute?  And if you go down that rabbit hole 
seriously, the regrettable conclusion is "PKI / x509 is not fit for 
purpose."  Which CAs can't abide bc it's their business model.  Let's 
Encrypt's 90 days is seriously annoying to them...

Browser manufacturers ofc don't have a clue about this stuff, they just 
believe and follow.


> <paranoia>If you prefer darker scenarios one could also think that 
> Google, as the driving force behind let's encrypt and Chrome, just 
> wants to harass other CAs.</paranoia> But since it's a valid point 
> that revocation is in fact not reliable, this proposal IMHO at least 
> deserves a serious discussion.


Once chrome happened, Google were the only ones who lived on both sides 
- browser *and* web commerce businesses.  Other players are typically 
only on one side, so they are blind to the other, which became seriously 
apparent when a hack occurred.  Exception is Microsoft, but they are 
famous non-carers.

So google have a less biased view now, forced on them by the dichotamy 
of chrome.  It also helps that Google have serious security architects, 
and took serious steps to rework things, which is just a no-no in the 
PKI world.  Eg QUIC and that transparency thing who's name eludes.  
Every other player is a taker of rules, which is how CAs like it.

I didn't know Google were behind Let's Encrypt... that explains a lot.

End of cynical rant, sunshine is out, gotta go :)

iang