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

Fri Jul 22 17:21:36 UTC 2016

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