<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ryan,<br>
As I believe I stated the last time I brought this up, I chose 6
months because I know for a fact that several member CAs plan their
dev roadmaps out that far because they have stated as much in
discussion of time tables on various ballots. And because I don't
think it is an excessive amount of time for a NON-CRITICAL update.
For this particular ballot or any other future ballot, less than 6
months may well be warranted, and that can be discussed both as the
ballot is being crafted and during the discussion phase as is being
done now. And for the record, you may be right in regards to this
particular ballot. Maybe it does warrant a shorter time to
compliance because it does affect the end customer, though for a CA
which is currently in compliance, I'd say that's for them to decide,
and for a CA which isn't, they could implement as soon as they can
make the requisite changes to their CPS (and since they're not
currently in compliance it would certainly be in their interest to
do so, and they likely don't require changes to their systems), so I
don't really see how this ballot constitutes a critical update, at
least not as I would define critical.<br>
<br>
My primary goal is to let everyone, including those who write the
audit standards, get out from behind the eight ball constantly
chasing ballots with immediate effect, which seems to be the current
default, by moving the default to 6 months. I think it fits well
with, say, a quarterly release cycle because it allows the CA to see
what's coming and plan for it, but not have to interrupt the current
in-development version with an emergency change. They can let the
current version proceed as planned, and add in whatever CA/B
required change into the next cycle.<br>
<br>
I've made my case why I think it's a reasonable default (twice now),
and stated that even though it would be the <i>default</i> it is
certainly mutable if the situation requires it. Please make your
case for why you don't.<br>
<br>
Regards,<br>
Rich<br>
<br>
<div class="moz-cite-prefix">On 7/22/2016 11:53 AM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvZZdxE6h+17unraWXrYvuxzvhOURWzruqqZdpVdt7MJwQ@mail.gmail.com"
type="cite">
<div dir="ltr">For an industry based on trust, 6 months to make
changes seems an exceptionally long time, and you haven't really
provided a justification for why that date over, say, 18 months,
3 months, or 3 days.
<div><br>
</div>
<div>I totally understand and appreciate changes take time, but
I still believe we need to take it on a case-by-case basis and
default to sooner, with a willingness to discuss what's
commercially reasonable or viable if some reason prevents it
being made sooner.</div>
<div><br>
</div>
<div>For example, consider the practical implications of this -
any CA that allows a subscriber to add and remove SANs from
certs, whether as part of a managed PKI or as part of a
product offering, is potentially in breach of this obligation
if they don't force a mandatory rekey (and I suspect many
don't, precisely because of the consumer hassle).</div>
<div><br>
</div>
<div>That is, if you have a cert for "<a moz-do-not-send="true"
href="http://a.example.com">a.example.com</a>" and "<a
moz-do-not-send="true" href="http://b.example.com">b.example.com</a>",
and you remove "<a moz-do-not-send="true"
href="http://b.example.com">b.example.com</a>" from the
cert, then according to this, the subscriber needs to request
revocation (the information is "incorrect" or "inaccurate"),
and needs to change keys.</div>
<div><br>
</div>
<div>Surely that's the kind of situation we'd rather fix sooner
than later, right? So if we said 45 days - or even went for an
even 60 - does that meet your needs?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 22, 2016 at 9:26 AM, Rich
Smith <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:richard.smith@comodo.com" target="_blank">richard.smith@comodo.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> I've said in the past
that I believe any non-critical change should have a 6
month lead time by default. I stand by that statement and
submit it again. And yes, Ryan, that goes whether the
change toughens or relaxes the requirements. CAs are of
course free and encouraged to bring themselves into
compliance sooner if they are able to do so without
turning their existing dev cycle on it's head, but I don't
think 6 months is unreasonable for a non-critical change
either way.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Rich</font></span>
<div>
<div class="h5"><br>
<br>
<div class="m_7461708476670458621moz-cite-prefix">On
7/21/2016 11:02 PM, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Dean,</p>
<p dir="ltr">In the past, when CAs have had
concerns, there's been a suggestion of a timeframe
that might be reasonable to make changes.</p>
<p dir="ltr">Is thirty days sufficient? Why or why
not?</p>
<p dir="ltr">When the proposed changes relax, rather
than toughen, a requirement, do you share the same
concerns?</p>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Jul 21, 2016 7:32 PM,
"Dean Coclin" <<a moz-do-not-send="true"
href="mailto:Dean_Coclin@symantec.com"
target="_blank">Dean_Coclin@symantec.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Josh,<br>
<br>
This is not a criticism of this specific
ballot; I have no comment on its merit.
However, in reviewing several recent ballots,
I think it's problematic to have a ballot
state that it is effective as of the date of
passage.<br>
<br>
If a CA has to make technical or policy
changes, it's going to take some time to do
so. If the ballot takes effect on the day of
passage, then the CA has to make immediate
changes, lest they be technically out of
compliance as of that day.<br>
<br>
For example, this ballot will require CAs to
make CPS changes. How are they supposed to do
this in one day? Am I reading this correctly?<br>
<br>
Thanks,<br>
Dean<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>]
On Behalf Of Josh Aas<br>
Sent: Thursday, July 14, 2016 10:18 AM<br>
To: CABFPub <<a moz-do-not-send="true"
href="mailto:public@cabforum.org"
target="_blank">public@cabforum.org</a>><br>
Subject: [cabfpub] Ballot 173 - Removal of
requirement to cease use of private key due to
incorrect certificate info<br>
<br>
Ballot 173 - Removal of requirement to cease
use of private key due to incorrect
certificate info<br>
<br>
The following motion has been proposed by Josh
Aas of ISRG / Let's Encrypt. Ben Wilson of
Digicert and Chris Bailey of Entrust endorse.<br>
<br>
Background:<br>
<br>
BR Section 9.6.3 point 5 says:<br>
<br>
"Reporting and Revocation: An obligation and
warranty to promptly cease using a Certificate
and its associated Private Key, and promptly
request the CA to revoke the Certificate, in
the event that: (a) any information in the
Certificate is, or becomes, incorrect or
inaccurate, or (b) there is any actual or
suspected misuse or compromise of the
Subscriber’s Private Key associated with the
Public Key included in the Certificate;"<br>
<br>
There is a problem here, which is that this
requires a subscriber to stop using a private
key just because information in a certificate
is inaccurate or incorrect. People should stop
using a cert with inaccurate or incorrect
information, but they shouldn't be required to
stop using a key pair unless there is known or
suspected compromise.<br>
<br>
This is particularly problematic for HPKP.<br>
<br>
--Motion Begins--<br>
<br>
Effective upon the date of passage, the
following modifications are made to the
Baseline Requirements:<br>
<br>
Change the following text in Section 9.6.3:<br>
=======================<br>
Reporting and Revocation: An obligation and
warranty to promptly cease using a Certificate
and its associated Private Key, and promptly
request the CA to revoke the Certificate, in
the event that: (a) any information in the
Certificate is, or becomes, incorrect or
inaccurate, or (b) there is any actual or
suspected misuse or compromise of the
Subscriber’s Private Key associated with the
Public Key included in the Certificate;
=======================<br>
<br>
To:<br>
=======================<br>
Reporting and Revocation: An obligation and
warranty to: (a) promptly request revocation
of the Certificate, and cease using it and its
associated Private Key, if there is any actual
or suspected misuse or compromise of the
Subscriber’s Private Key associated with the
Public Key included in the Certificate; and
(b) promptly request revocation of the
Certificate, and cease using it, if any
information in the Certificate is or becomes
incorrect or inaccurate.<br>
=======================<br>
<br>
--Motion Ends--<br>
<br>
The review period for this ballot shall
commence at 2200 UTC on 14 July 2016, and will
close at 2200 UTC on 21 July 2016. Unless the
motion is withdrawn during the review period,
the voting period will start immediately
thereafter and will close at 2200 UTC on 28
July 2016. Votes must be cast by posting an
on-list reply to this thread.<br>
<br>
A vote in favor of the motion must indicate a
clear 'yes' in the response. A vote against
must indicate a clear 'no' in the response. A
vote to abstain must indicate a clear
'abstain' in the response.<br>
Unclear responses will not be counted. The
latest vote received from any representative
of a voting member before the close of the
voting period will be counted. Voting members
are listed here:<br>
<a moz-do-not-send="true"
href="https://cabforum.org/members/"
rel="noreferrer" target="_blank">https://cabforum.org/members/</a><br>
<br>
In order for the motion to be adopted, two
thirds or more of the votes cast by members in
the CA category and greater than 50% of the
votes cast by members in the browser category
must be in favor. Quorum is currently ten (10)
members– at least ten members must participate
in the ballot, either by voting in favor,
voting against, or abstaining.<br>
<br>
--<br>
Josh Aas<br>
Executive Director<br>
Internet Security Research Group<br>
Let's Encrypt: A Free, Automated, and Open CA
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org"
target="_blank">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a moz-do-not-send="true"
href="mailto:Public@cabforum.org"
target="_blank">Public@cabforum.org</a><br>
<a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"
rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset
class="m_7461708476670458621mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Public mailing list
<a moz-do-not-send="true" class="m_7461708476670458621moz-txt-link-abbreviated" href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a>
<a moz-do-not-send="true" class="m_7461708476670458621moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<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"
rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>