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

Fri Jul 22 17:34:47 UTC 2016

On 7/22/2016 12:21 PM, Josh Aas wrote:
> 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.
Unfortunately, Josh, you figured right.  IMO 'immediate effect' is the 
go-to default for just about every ballot and only gets changed (or even 
thought about) if someone objects.  That's what I'm proposing to 
change.  Let's move as to group to a default of plenty of lead time (we 
can debate what that is, but let's agree that it's definitely NOT 
'immediate effect') , and we can shorten it if there is a compelling 
reason to do so.
>
> 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
>>
>
>