[cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info
Rich Smith
richard.smith at comodo.com
Fri Jul 22 10:27:18 MST 2016
Ryan,
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.
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.
I've made my case why I think it's a reasonable default (twice now), and
stated that even though it would be the /default/ it is certainly
mutable if the situation requires it. Please make your case for why you
don't.
Regards,
Rich
On 7/22/2016 11:53 AM, Ryan Sleevi wrote:
> 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.
>
> 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.
>
> 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).
>
> That is, if you have a cert for "a.example.com <http://a.example.com>"
> and "b.example.com <http://b.example.com>", and you remove
> "b.example.com <http://b.example.com>" from the cert, then according
> to this, the subscriber needs to request revocation (the information
> is "incorrect" or "inaccurate"), and needs to change keys.
>
> 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?
>
> On Fri, Jul 22, 2016 at 9:26 AM, Rich Smith <richard.smith at comodo.com
> <mailto:richard.smith at comodo.com>> wrote:
>
> 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.
>
> -Rich
>
>
> On 7/21/2016 11:02 PM, Ryan Sleevi wrote:
>>
>> Dean,
>>
>> In the past, when CAs have had concerns, there's been a
>> suggestion of a timeframe that might be reasonable to make changes.
>>
>> Is thirty days sufficient? Why or why not?
>>
>> When the proposed changes relax, rather than toughen, a
>> requirement, do you share the same concerns?
>>
>>
>> On Jul 21, 2016 7:32 PM, "Dean Coclin" <Dean_Coclin at symantec.com
>> <mailto:Dean_Coclin at symantec.com>> wrote:
>>
>> Josh,
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> Thanks,
>> Dean
>>
>>
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org
>> <mailto:public-bounces at cabforum.org>
>> [mailto:public-bounces at cabforum.org
>> <mailto:public-bounces at cabforum.org>] On Behalf Of Josh Aas
>> Sent: Thursday, July 14, 2016 10:18 AM
>> To: CABFPub <public at cabforum.org <mailto:public at cabforum.org>>
>> Subject: [cabfpub] Ballot 173 - Removal of requirement to
>> cease use of private key due to incorrect certificate info
>>
>> Ballot 173 - Removal of requirement to cease use of private
>> key due to incorrect certificate info
>>
>> The following motion has been proposed by Josh Aas of ISRG /
>> Let's Encrypt. Ben Wilson of Digicert and Chris Bailey of
>> Entrust endorse.
>>
>> Background:
>>
>> BR Section 9.6.3 point 5 says:
>>
>> "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;"
>>
>> 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.
>>
>> This is particularly problematic for HPKP.
>>
>> --Motion Begins--
>>
>> Effective upon the date of passage, the following
>> modifications are made to the Baseline Requirements:
>>
>> Change the following text in Section 9.6.3:
>> =======================
>> 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; =======================
>>
>> To:
>> =======================
>> 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.
>> =======================
>>
>> --Motion Ends--
>>
>> 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.
>>
>> 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.
>> 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:
>> https://cabforum.org/members/
>>
>> 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.
>>
>> --
>> Josh Aas
>> Executive Director
>> Internet Security Research Group
>> Let's Encrypt: A Free, Automated, and Open CA
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org>
>> https://cabforum.org/mailman/listinfo/public
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160722/d44f26de/attachment-0001.html
More information about the Public
mailing list