<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
By not making a change in the BRs, the CAB Forum is essentially
saying CAs can't use expiration as a means of revocation. Without
the benefit provided by short lived certs, you won't have
subscribers using them.<br>
<br>
Jeremy<br>
<br>
<div class="moz-cite-prefix">On 10/28/2014 7:49 AM, Phillip
Hallam-Baker wrote:<br>
</div>
<blockquote
cite="mid:53920F8F-5FA0-44D5-A5A4-0141C9CC0E1D@comodo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Which is why I disagreed with Gerv’s claim that there is no
point to issuing short lived certs with the revocation
indicators present. The point is that it establishes a base of
deployment that can then be used to justify the necessary
changes in the BRs.</div>
<div><br>
</div>
<div>The reason that I am interested in short lived certs even
with the compressed CRL technology is because even a compressed
delta CRL is still a list. The scaling issue is postponed, not
eliminated.</div>
<div><br>
</div>
<div>If however we combine short lived certs with compressed CRLs
we can reduce the vulnerability window from days to hours. Which
is a big gain because it would mean that we likely remove the
incentive to attempt an attack.</div>
<div><br>
</div>
<div><br>
</div>
<div>The secret to keeping Disneyland clean is that the park is
already clean. People feel bad about littering if the place is
clean. If there is litter they don’t feel bad about making more.</div>
<div><br>
</div>
<br>
<div>
<div>On Oct 27, 2014, at 10:26 PM, <a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 18px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;">Not everyone agrees at this point that the risk
profile of short-lived certs that can't be recalled (no
revocation checking possible) is equivalent to the risk
profile of long-lived certs with revocation checking but
with all the limitations discussed.<br>
<br>
Leaving the decision on whether to accept short-lived certs
with no revocation checking to the interested browsers and
interested CAs means that other CAs and browsers don't have
to approve or participate -- and no changes to the BRs would
be required.<br>
<br>
-----Original Message-----<br>
From: Jeremy Rowley [<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com">mailto:jeremy.rowley@digicert.com</a>]<span
class="Apple-converted-space"> </span><br>
Sent: Monday, October 27, 2014 6:26 PM<br>
To: Kirk Hall (RD-US); Gervase Markham; Tim Hollebeek;<a
moz-do-not-send="true" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: RE: [cabfpub] Pre-Ballot - Short-Life Certificates<br>
<br>
If short-lived certs are an acceptable form of revocation
checking, then what advantage is there to use a phased-in
approach with customer browser code? You get the same
benefits with no changes by simply omitting the revocation
pointers. I don't see what risks are mitigated by phasing
in short-lived certs only for new browsers. <br>
<br>
Jeremy<br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
On Behalf Of <a moz-do-not-send="true"
href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a><br>
Sent: Monday, October 27, 2014 5:44 PM<br>
To: Gervase Markham; Tim Hollebeek; <a
moz-do-not-send="true" href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates<br>
<br>
Gerv, I've pasted in your original response to this question
below. <br>
<br>
If I can summarize, you don't want revocation pointers in
new "short lived certs" as defined because legacy browsers
and apps (i.e., every browser and app in use today) will
continue to check for revocation information, thereby
lowering the benefit of this new type of cert. (You
estimated 90% will still check for revocation -- but is that
number realistic under Google's and Mozilla's current
revocation checking processes? I thought revocation
checking was already omitted today for many long-lived
certs...)<br>
<br>
My question back is: how long would it take Firefox and
Google (and other interested browsers) to modify your
browser software as Tim and Rich have suggested - ignore
revocation pointers if the cert is a short lived cert? And
how quickly would those code changes get distributed to your
users?<br>
<br>
The burden of revocation checking falls mostly on CAs, and
it can only get better (fewer revocation checks) if some
browsers decide not to check revocation for
(self-designated) short lived cert by modifying their
software. So why not just move forward as browsers to do
this? The revocation checking burden on CAs that decide to
start issuing short-lived certs would not go up as compared
to current long lived certs, and over time (maybe quickly)
would go down.<br>
<br>
Having said that, Trend Micro is not yet convinced this is a
good idea for the reasons stated by others -- but the
browsers don't have to wait if they think the risk from
eliminating revocation checking for short lived certs is
acceptable.<br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
On Behalf Of Gervase Markham<br>
Sent: Monday, October 27, 2014 12:33 PM<br>
To: Tim Hollebeek; <a moz-do-not-send="true"
href="mailto:public@cabforum.org">public@cabforum.org</a><br>
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates<br>
<br>
On 27/10/14 14:14, Tim Hollebeek wrote:<br>
<blockquote type="cite">What does not having the revocation
information in the cert actually solve?<br>
</blockquote>
<br>
I've covered this earlier in the thread :-)<br>
<br>
Gerv<br>
_______________________________________________<br>
<br>
On 24/10/14 13:40, Rich Smith wrote:<br>
<blockquote type="cite">I keep coming back to this same
question every time this comes up, and<span
class="Apple-converted-space"> </span><br>
I have not received a satisfactory answer yet:<br>
Why MUST a short lived certificate be issued without
containing<span class="Apple-converted-space"> </span><br>
revocation information?<br>
</blockquote>
<br>
And I keep asking it every time you ask: because putting in
revocation information eliminates 90% of their advantage,
because there is then no advantage in all the
currently-existing clients. A short-lived cert with
revocation pointers will still incur the delay of revocation
checking, even though (this is the argument, and the
argument with which I hope you will engage) it's not
necessary to provide them because the security properties of
a 3-day cert are broadly comparable to a 1-year cert with
10-day, 5-day or 3-day-expiry OCSP responses.<br>
<br>
<blockquote type="cite">The simple fact of the matter is
that revocation info in the<span
class="Apple-converted-space"> </span><br>
certificate MAY help SOME users IF the certificate gets
revoked, and I<span class="Apple-converted-space"> </span><br>
have yet to see anyone offer up any decent argument for
why the<span class="Apple-converted-space"> </span><br>
revocation info absolutely MUST NOT be present for
short-lived certs to work.<br>
</blockquote>
<br>
No one is arguing that it MUST NOT be present for
short-lived certificates to "work". But if a site and a CA
are together considering deploying such a technology, they
will look at the costs and benefits.<br>
There will be significant costs in setting up the system; if
the benefits are only in 5% or 10% of clients, it may well
be judged not to be worth it.<br>
<br>
<blockquote type="cite">I'm open<br>
to such an argument, but until I see it I remain opposed
to a ballot<span class="Apple-converted-space"> </span><br>
to allow any certificate to be issued without revocation
information.<br>
</blockquote>
<br>
I don't understand this position. Surely the acceptability
or not of short-lived certificates should depend on whether
their security properties are broadly comparable to existing
solutions, not on whether I can construct an argument that
shows it's required to remove the revocation information for
it to be technically feasible to deploy them?<br>
<br>
Gerv<br>
<table
class="TM_EMAIL_NOTICE"><tr><td><pre><br>
TREND MICRO EMAIL NOTICE<br>
The information contained in this email and any attachments
is confidential and may be subject to copyright or other
intellectual property protection.<span
class="Apple-converted-space"> </span><br>
If you are not the intended recipient, you are not
authorized to use or disclose this information, and we
request that you notify us by reply mail or telephone and
delete the original message from your mail system.<br>
</pre></td></tr></table><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true" href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><br>
<table
class="TM_EMAIL_NOTICE"><tr><td><pre><br>
TREND MICRO EMAIL NOTICE<br>
The information contained in this email and any attachments
is confidential<span class="Apple-converted-space"> </span><br>
and may be subject to copyright or other intellectual
property protection.<span class="Apple-converted-space"> </span><br>
If you are not the intended recipient, you are not
authorized to use or<span class="Apple-converted-space"> </span><br>
disclose this information, and we request that you notify us
by reply mail or<br>
telephone and delete the original message from your mail
system.<br>
</pre></td></tr></table><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true" href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a></div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>