[cabfpub] Ballot 164 - Certificate Serial Number Entropy

Rob Stradling rob.stradling at comodo.com
Wed Jul 6 09:24:28 UTC 2016


Comodo votes YES.

On 24/06/16 16:17, Ben Wilson wrote:
> *Ballot 164 - Certificate Serial Number Entropy*
>
>
>
> This ballot has been proposed by Jacob Hoffman-Andrews of Let's Encrypt
> and endorsed by Ben Wilson of DigiCert and Tim Hollebeek of Trustwave:
>
>
>
> *Statement of intent:*
>
>
>
> As demonstrated in
> https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf,
> hash collisions can allow an attacker to forge a signature on the
> certificate of their choosing. The birthday paradox means that, in the
> absence of random bits, the security level of a hash function is half
> what it should be. Adding random bits to issued certificates mitigates
> collision attacks and means that an attacker must be capable of a much
> harder preimage attack. For a long time the Baseline Requirements have
> encouraged adding random bits to the serial number of a certificate, and
> it is now common practice. This ballot makes that best practice
> required, which will make the Web PKI much more robust against all
> future weaknesses in hash functions. Additionally, it replaces "entropy"
> with "CSPRNG" to make the requirement clearer and easier to audit, and
> clarifies that the serial number must be positive.
>
>
>
> *-- Motion Begins --*
>
>
>
> In Section 1.6.1 of the Baseline Requirements,
>
>
>
> ADD
>
>
>
> CSPRNG: A random number generator intended for use in cryptographic system.
>
>
>
>
>
> In Section 7.1 of the Baseline Requirements,
>
>
>
> REPLACE
>
>
>
> "CAs SHOULD generate non-sequential Certificate serial numbers that
> exhibit at least 20 bits of entropy."
>
>
>
> WITH
>
>
>
> "Effective September 30, 2016, CAs SHALL generate Certificate serial
> numbers greater than zero (0) containing at least 64 bits of output from
> a CSPRNG."
>
>
>
> *-- Motion Ends --*
>
>
>
> The review period for this ballot shall commence immediately, and will
> close at 2200 UTC on 1 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 8 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.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online




More information about the Public mailing list