On 15/03/2019 13:26, Peter Gutmann via dev-security-policy wrote:
I actually thought it was from "Chosen-prefix collisions for MD5 and
applications" or its companion papers ("Short chosen-prefix collisions for MD5
and the creation of a rogue CA certificate", "Chosen-Prefix Collisions for MD5
and
On 15/03/2019 07:13, Jaime Hablutzel via dev-security-policy wrote:
64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
CSPRNG with at least one bit in the highest byte set to 1
is, strictly speaking, not true. The best possible implementation for
GetRandom64Bits(), as
> Lastly, it was identified\discussed since we were STARTING with 64bits it was
> acceptable. Therefore, GoDaddy was in compliance prior to 3/7. After this
> discussion we changed back to the pre 3/7 configuration on 3/13.
Thanks for the additional explanation, greatly appreciated.
>From
On Friday, March 15, 2019 at 12:53:15 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> > On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > > On Wednesday,
On Friday, March 15, 2019 at 12:45:39 PM UTC-7, Ryan Sleevi wrote:
> On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> > >
> > > > In
On Fri, Mar 15, 2019 at 3:35 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> > On Wednesday, March 13, 2019 at 8:17:00 PM UTC-4, Daymion Reynolds wrote:
> >
> > > In accordance with our conversations to date, prior to 3/7 6:30pm AZ
> we utilized raw
On Friday, March 15, 2019 at 12:35:47 PM UTC-7, Daymion Reynolds wrote:
> On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> > Daymion,
> >
> > (Apologies in advance if I've missed something that led to these results.
> > These results rely on the crt.sh database,
On Friday, March 15, 2019 at 12:25:37 PM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
>
> (Apologies in advance if I've missed something that led to these results.
> These results rely on the crt.sh database, which I will admit to being less
> familiar with than I would like.)
>
> While
Daymion,
(Apologies in advance if I've missed something that led to these results. These
results rely on the crt.sh database, which I will admit to being less familiar
with than I would like.)
While recently looking at some randomly selected recent certificates from this
CA:
On Fri, Mar 15, 2019 at 8:54 AM Andrew via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Perhaps the solution should be to amend the BRs to allow for more flexible
> handling of situations such as this.
>
>
After a long debate, the BR revocation requirements were recently
Perhaps the solution should be to amend the BRs to allow for more flexible
handling of situations such as this.
I understand that'd be rather difficult to formalize, since we can't just trust
the CAs to decide for themselves when mass revocation doesn't make sense (as
they have a vested
On Fri, Mar 15, 2019 at 12:36 AM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Could you please provide me a link to a previous discussion where the
> negative was stated, maybe by the module owner?. But note that I'm not
> asking for a bespoke or
> > So I would like to ask again if there is any possibility to implement some
> > type of exceptions handling as asked in [2].
> >
>
> This has been repeatedly and unambiguously answered: categorically, the
> answer is no.
Could you please provide me a link to a previous discussion where the
Jaime Hablutzel via dev-security-policy
writes:
>>>Again, maths were wrong here, sorry. Correct calculation is:
>>>
>>>log2(18446744073708551615) = 63.93
>>
>>I love the way that people are calculating data on an arbitrarily-chosen value
>>pulled entirely out of thin air
>
>Can
Hi Daymion, in [1] you said before:
> For the DER format the first two (0)s of the value is the positive sign of
> the integer. In our case if the un-signed integer value is 64bit and the most
> significant bit is set, two additional (0)s will be prepended to demonstrate
> a positive sign. In
On Thu, Mar 14, 2019 at 4:33 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:
>
> > I'd already asked previously whether any CA wanted to indicate publicly
> that
> > they were compliant
> >Again, maths were wrong here, sorry. Correct calculation is:
> >
> >log2(18446744073708551615) = 63.93
>
> I love the way that people are calculating data on an arbitrarily-chosen value
> pulled entirely out of thin air
Can you confirm if the motivation for the "64 bits of output
On Thu, Mar 14, 2019 at 11:16 PM Jaime Hablutzel via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> So I would like to ask again if there is any possibility to implement some
> type of exceptions handling as asked in [2].
>
This has been repeatedly and unambiguously
> So you can argue that it's not possible to comply with the BRs by
> just generating a 64 bit random number, you would need to generate
> at least 65.
Yes, that's right, because the 64 bit entropy won't be left intact after any
filtering, even the very basic zero value removal.
> But I would
Jaime Hablutzel via dev-security-policy
writes:
>Again, maths were wrong here, sorry. Correct calculation is:
>
>log2(18446744073708551615) = 63.93
I love the way that people are calculating data on an arbitrarily-chosen value
pulled entirely out of thin air to 14 decimal places.
On Thursday, March 14, 2019 at 6:09:21 PM UTC-5, Jaime Hablutzel wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls for us to modify our
On Thursday, March 14, 2019 at 5:13:51 PM UTC-5, Jaime Hablutzel wrote:
> > 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
> > CSPRNG with at least one bit in the highest byte set to 1
> >
> > is, strictly speaking, not true. The best possible implementation for
> >
On Thu, Mar 14, 2019 at 04:09:10PM -0700, Jaime Hablutzel via
dev-security-policy wrote:
> > In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> > utilized raw 64 bit output from CSPRING, with uniqueness and non zero
> > checks. This new understanding of the rules calls
> In accordance with our conversations to date, prior to 3/7 6:30pm AZ we
> utilized raw 64 bit output from CSPRING, with uniqueness and non zero checks.
> This new understanding of the rules calls for us to modify our original
> disclosure to 0 affected certificates.
"uniqueness and non zero
On Thursday, March 14, 2019 at 3:13:51 PM UTC-7, Jaime Hablutzel wrote:
> > 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
> > CSPRNG with at least one bit in the highest byte set to 1
> >
> > is, strictly speaking, not true. The best possible implementation for
> >
> 64bits_entropy = GetRandom64Bits() //This returns 64 random bits from a
> CSPRNG with at least one bit in the highest byte set to 1
>
> is, strictly speaking, not true. The best possible implementation for
> GetRandom64Bits(), as described, only returns 63.994353 bits of entropy,
> not 64.
>
On Wednesday, March 13, 2019 at 9:09:35 PM UTC-4, Peter Gutmann wrote:
> Richard Moore via dev-security-policy
> writes:
>
> >If any other CA wants to check theirs before someone else does, then now is
> >surely the time to speak up.
>
> I'd already asked previously whether any CA wanted to
On 14/03/2019 01:09, Peter Gutmann via dev-security-policy wrote:
> I'd already asked previously whether any CA wanted to indicate publicly that
> they were compliant with BR 7.1, which zero CAs responded to (I counted them
> twice).
Peter,
Mozilla Root Store Policy section 2.3 [1] requires CAs
On 13/03/2019 22:28, Richard Moore via dev-security-policy wrote:
> On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote:
>>
>> The expected distribution when generating a random 64 bit integer
>> and properly encoding that as DER is that:
>> - about 1/2 integers require 9 bytes
>> -
: Re: Pre-Incident Report - GoDaddy Serial Number Entropy
On Wed, Mar 13, 2019 at 6:09 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Richard Moore via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
>
On Wed, Mar 13, 2019 at 6:09 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Richard Moore via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >If any other CA wants to check theirs before someone else does, then now
> is
>
Richard Moore via dev-security-policy
writes:
>If any other CA wants to check theirs before someone else does, then now is
>surely the time to speak up.
I'd already asked previously whether any CA wanted to indicate publicly that
they were compliant with BR 7.1, which zero CAs responded to (I
On Thursday, March 7, 2019 at 7:01:41 PM UTC-7, Daymion Reynolds wrote:
> As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate
> Serial Number issue. We have identified a significant quantity of
> certificates (> 1.8million) not meeting the 64bit serial number requirement.
On Tuesday, March 12, 2019 at 11:53:25 PM UTC, Kurt Roeckx wrote:
>
> The expected distribution when generating a random 64 bit integer
> and properly encoding that as DER is that:
> - about 1/2 integers require 9 bytes
> - about 1/2 integers require 8 bytes
> - about 1/512 integers require 7
On Wed, Mar 13, 2019 at 05:56:55AM +0900, Hector Martin 'marcan' via
dev-security-policy wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only
On Tue, Mar 12, 2019 at 4:57 PM Hector Martin 'marcan'
wrote:
> On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> > Note that even 7 bytes or less may still be valid - for example, if the
> > randomly generated integer was 4 [1], you might only have a one-byte
> serial
> > in
On 13/03/2019 05.38, Ryan Sleevi via dev-security-policy wrote:
> Note that even 7 bytes or less may still be valid - for example, if the
> randomly generated integer was 4 [1], you might only have a one-byte serial
> in encoded form ( '04'H ), and that would still be compliant. The general
>
On Tue, Mar 12, 2019 at 4:23 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> > On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy
> <
> >
On Tuesday, March 12, 2019 at 11:32:38 AM UTC-7, Ryan Sleevi wrote:
> On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > The crux of the difference is in the DER format interpretation. The fact
> > prefix (0)s do count
On Tue, Mar 12, 2019 at 2:22 PM Daymion Reynolds via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> The crux of the difference is in the DER format interpretation. The fact
> prefix (0)s do count for entropy, provided none of the bits are fixed and
> you have a minimum of 8
On Tuesday, March 12, 2019 at 9:54:56 AM UTC-7, ad...@adamcaudill.com wrote:
> Daymion,
>
> You linked to a thread in m.d.s.p and cited it as confirming a specific
> interpretation of 7.1 - as that's a long thread (with some possible
> questionable information), could you possibly share what
Daymion,
You linked to a thread in m.d.s.p and cited it as confirming a specific
interpretation of 7.1 - as that's a long thread (with some possible
questionable information), could you possibly share what criteria you used to
determine what certificates were impacted by this issue and which
As of 9pm AZ on 3/6/2019 GoDaddy started researching the 64bit certificate
Serial Number issue. Due to a m.d.s.p.[1] discussion validating an
interpretation of BR 7.1 our revised count is approximately 12,152 live
certificates not meeting the 64bit serial number requirement. Additionally, we
On Fri, Mar 8, 2019 at 8:26 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Daymion Reynolds via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
>
> >Our goal is to reissue all the certificates within the next 30 days.
>
> Before
On Fri, Mar 08, 2019 at 09:35:21PM +, Jeremy Rowley via
> dev-security-policy wrote: If they need some help with large scale
> replacement, I know some people who did that recently. Joking of
> course, but really - with Godaddy, Google, and Apple reporting a large
> number of certs that have
Daymion Reynolds via dev-security-policy
writes:
>Our goal is to reissue all the certificates within the next 30 days.
Before everyone goes into an orgy of mass revocation, see the message I just
posted "Why BR 7.1 allows any serial number except 0". As long as your serial
number isn't zero,
Our goal is to reissue all the certificates within the next 30 days. We have
started the revocation process. We have a significant number of customers that
use manual methods for managing their certificates, so being agile for them is
difficult. We want to keep our customers using https through
On Fri, Mar 8, 2019 at 4:03 PM Jeremy Rowley
wrote:
> Apologies, I realize that Mozilla’s policy is that revocation is up to the
> CA and there is no such thing as an exception. A more careful way to state
> what I meant is that I’m surprised that there is not more discussion around
> the
and cons of doing so.
From: Wayne Thayer
Sent: Friday, March 8, 2019 3:46 PM
To: Ryan Sleevi
Cc: Jeremy Rowley ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy
Ryan beat me to the punch. so I'll reinforce his message with my own
Ryan beat me to the punch. so I'll reinforce his message with my own:
The overall potential impact from revocations in the current scenario feels
quite similar to the potential for disruption from revoking certificates
containing underscores a few months ago. Mozilla's guidance for revocation
[1]
On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> does Mozilla want to require a complete revocation and replacement? Seems
> like a lot of effort and disruption for little value to the Mozilla
> community.
I'm surprised,
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy
On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to
> track this issue.
>
> Apple has al
On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
> this issue.
>
> Apple has also submitted the following bug for this issue listing a large
> number of impacted certificates:
>
I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to track
this issue.
Apple has also submitted the following bug for this issue listing a large
number of impacted certificates:
https://bugzilla.mozilla.org/show_bug.cgi?id=1533655
- Wayne
On Thu, Mar 7, 2019 at 7:14 PM Matthew
Practical question:
How does the update to CABLint/Zlint work?
If a CA is choosing to issue certs with serial numbers with exactly 64 bits
of entropy, approximately 50% of the time there will be a certificate with
an 8 byte encoding of the serial number, as the high-order bit of the first
byte
55 matches
Mail list logo
