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

Dean Coclin Dean_Coclin at symantec.com
Fri Jul 22 21:41:46 UTC 2016 

Thanks, that works for me.

Dean

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Josh Aas
Sent: Friday, July 22, 2016 3:42 PM
To: Peter Bowen <pzb at amzn.com>
Cc: Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 173 - Removal of requirement to cease use of private key due to incorrect certificate info

It seems most expedient to just agree to a 45 day waiting period to move things along if that lets us continue voting on the original ballot now and be done with it. Then we can debate waiting periods for future ballots in another thread. Changing the actual content of a ballot (e.g. pzb's proposal) should probably require a new review period.

So - I propose that this ballot take effect 45 days after passing, and that voting continue now.

On Fri, Jul 22, 2016 at 1:28 PM, Peter Bowen <pzb at amzn.com> wrote:
> What if we solve it by making the following change instead of the original proposal?
>
> 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 either:
>
> (1) 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; or
>
> (2) (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.
> =======================
>
> This would mean all current subscriber agreements are fine and CAs have the option to be less restrictive if they so wish in future versions of their agreements.  It could take effect immediately as it has no deadline for a CA to make a change.
>
> Thanks,
> Peter
>
>> On Jul 22, 2016, at 11:11 AM, Dean Coclin <Dean_Coclin at symantec.com> wrote:
>>
>> Josh,
>> Not blaming you at all for copying a prior ballot as that's what most people would do anyway. What I would like you and the ballot proponents to consider though is what I stated in my prior message. CAs follow a change control process, whether it be for software, policies or legal documents. This ballot will requires changes to the CPS and Subscriber agreement. Some reasonable time should be granted to CAs to make those changes. My suggestion was 45 days. I don't think 6 months is necessary here.
>>
>> Thanks
>> Dean
>>
>> -----Original Message-----
>> From: public-bounces at cabforum.org 
>> [mailto:public-bounces at cabforum.org] On Behalf Of Josh Aas
>> Sent: Friday, July 22, 2016 1:22 PM
>> To: Ryan Sleevi <sleevi at google.com>
>> Cc: CABFPub <public at cabforum.org>
>> Subject: Re: [cabfpub] Ballot 173 - Removal of requirement to cease 
>> use of private key due to incorrect certificate info
>>
>> I agree that lead time for changes is normally a good idea. There are two reasons I wrote this ballot the way I did:
>>
>> 1) I copied the language from a past ballot, the first past ballot I happened to click on, so I figured it was standard procedure for this group. If it's not then you can chalk that up to my inexperience.
>>
>> 2) This change corrects a pretty straightforward and non-controversial (from what I can tell) mistake in the BRs. I don't see any justification for a waiting period during which CAs might be forced to make a choice between something that doesn't make any sense (denying re-use of a perfectly good key pair) and non-compliance.
>>
>> On Fri, Jul 22, 2016 at 11:53 AM, Ryan Sleevi <sleevi at google.com> 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" and "b.example.com", 
>>> and you remove "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>
>>> 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> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> Public mailing list
>>> Public at cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>>
>>
>>
>>
>> --
>> 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
>



--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160722/ccd1b542/attachment-0001.p7s>

More information about the Public mailing list