[cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info

Ryan Sleevi sleevi at google.com
Fri Jul 22 04:02:16 UTC 2016


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> 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] On
> Behalf Of Josh Aas
> Sent: Thursday, July 14, 2016 10:18 AM
> To: CABFPub <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
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160721/ffae1dfd/attachment-0003.html>


More information about the Public mailing list