Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 improvised exception for the current issue but for > the possibility to introduce a procedure to handle any type of low > breach/high disruption violations now and in the future?. > "However, Mozilla does not grant exceptions to the BR revocation requirements." [1] "In my opinion, Mozilla should not get in to the business of granting one-off exceptions ..." [2] [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/HNDX5LaZCAAJ (That's this thread, one week ago) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> > 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 negative was stated, maybe by the module owner?. But note that I'm not asking for a bespoke or improvised exception for the current issue but for the possibility to introduce a procedure to handle any type of low breach/high disruption violations now and in the future?. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 you confirm if the motivation for the "64 bits of output from a CSPRNG"
>can be found in [1]?.
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 Colliding X.509 Certificates for Different Identities"), but it's not in
any of those. Even the CCC talk slides only say "We need defense in depth ->
random serial numbers" without giving a bit count. So none of the original
cryptographic analysis papers seem to give any value at all. It really does
seem to be a value pulled entirely out of thin air.
Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 this case it will be 9bytes instead of 8bytes. Always a > minimum of 8bytes (64bits) of entropy. You do still have to manage zero > compression for integer values less than 72057594037927936, which will result > in 7bytes instead of 8bytes. Implying that you were preventing an encoding shorter than 8 bytes by filtering values lower than 01 00 00 00 00 00 00 00 (which, by the way, is unnecesarily high to avoid compression as 80 00 00 00 00 00 00 suffices). But then you said: > RS - The reduction from >1.8M certificates to 12K certificates is a statement > that only those 12K certificates lacked a 64-bit entropy contribution? > DR – Yes, the 12k certs are only 7bytes or less and therefor do not meet the > BRs. Confirming that you were not filtering out serial numbers shorter than 8 bytes, which contradicts the previous. Can you please clarify?. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/E7uzTWDDBwAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 with BR 7.1, which zero CAs responded to (I counted > them > > twice). > > Peter, > > Mozilla Root Store Policy section 2.3 [1] requires CAs to conform to the > latest version of the Baseline Requirements. So ISTM that until or > unless a CA publicly states that they are non-compliant with BR 7.1, we > should act as if that CA has publicly stated that they are compliant > with BR 7.1. > > FWIW though, you can find a public statement from Sectigo at [2]. > > > [1] > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance > > [2] > > https://sectigo.com/blog/all-sectigo-public-certificates-meet-64-bit-serial-number-requirements As I posted in a related thread, we can see that both Boulder and R509 implement serial generation which conforms to BR 7.1. Both of these are open source open source CA software packages that were written by organizations that run CAs in the mozilla program. Unless the public code has different generation semantics than the production code (which would be very strange), one can surmise users of these packages are compliant. Additionally many other CAs are known to have built their own software and/or use software other than EJBCA, so making any generalization isn't really valid. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> >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 from a CSPRNG" can be found in [1]?. > to 14 decimal places. It's like summing a > diverging series. Or calculating how many angels can fit on the head of a > pin. Or something. > > Peter. [1] https://www.mail-archive.com/search?l=pub...@cabforum.org=subject:%22Re%5C%3A+%5C%5Bcabfpub%5C%5D+Pre%5C-Ballot+164+%5C-+Certificate+Serial+Number+Entropy%22=newest ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 answered: categorically, the answer is no. The analysis and discussion so far is not only demonstrative of what CAs COULD have done, but what CAs SHOULD have done. If one imagines generating 2^64 certificates, they might pick serials of 2^128 bits of entropy. It has been repeatedly addressed, for years, in this forum that exceptions are not granted, and are fundamentally detrimental to the goals of a transparent and equitable set of expectations for CAs. There's no need to relitigate that, nor is it appropriate, considering that every matter of CA non-compliance seems to invoke the same conversation. CAs are ultimately responsible for their compliance and for their actions following non-compliance. The revocation policy has been repeatedly clarified, both individually and generally, as to the expectations. It's a mistake to conflate non-compliance as a guaranteed removal, just as it's a mistake to conflate (seeming) compliance with guaranteed inclusion. Trust is not guaranteed - it's earned, by demonstration of awareness, knowledge, and responsive handling of issues that demonstrate a holistic understanding of the issues and risks and a reasonable and consistent responsiveness. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> 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 argue that such an implementation that > only generates 64 bits and does the checks is in the spirit of what > was intended. I'm not sure if that could be the intent because it would allow the following to happen: Let's say that the biggest CA in the universe (serving other planets too) has issued the following number of certificates to the time, 18446744073709551614 (2^64 - 2), and now they need to generate a new certificate and there is only one possible serial number to choose from (the other value is the forbidden zero) and the purpose of ballot 164 (i.e. protect against https://fahrplan.events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf) is defeated. Anyway, the previous is a non-realistic example and I'm well aware that the mass violation under discussion won't affect security in the real world now, but given that in this very moment this is the formally implemented requirement, all violations should be treated according to the regular procedure, unless... The Mozilla Root Store Policy gets updated with an exceptions handling procedure which could "forgive" retroactively (possible?) this massive violation, e.g. allowing a minimum entropy of 62 bits (or less) for certificates issued until a given date (in the near future) with the purpose to accomodate to the 62 bits [1] of entropy being guaranteed by a default EJBCA <7.0.1 or to the entropy provided by any other known PKI implementation. So I would like to ask again if there is any possibility to implement some type of exceptions handling as asked in [2]. [1] log2(0x7FFF - 0x80 + 1) = 62.99435343685886 (or less if certificates has been previously generated) [2] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7WuWS_20758/erK0-f0GCwAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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. It's like summing a diverging series. Or calculating how many angels can fit on the head of a pin. Or something. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 > > original disclosure to 0 affected certificates. > > "uniqueness and non zero checks" have crippled the effective 64 bit output > from the CSPRNG, so, as I can see it, all of your previously generated serial > numbers (according to the algorithm you disclosed [1]) could be considered > non-compliant to current BRs as explained below: > > First, according to your algorithm, if the MSB in the fully random 8 octets > is 1 you add a leading 00 byte, so until that time you have 64 full bits of > entropy, i.e. 18446744073709551616 possible different values. > > Then, you have to filter out some values. To begin with, you filter out the > value 0, leaving you with 18446744073709551615 possible values. > > Now, you filter the previosly generated serial numbers (known to potential > attackers thanks to current CT deployment), let's say 100 at a given > point in time, so now you are left with 18446744073708551615 possible values. > > And if we do the math: > > 18446744073708551615 / 18446744073709551616 * 64 = > 63.9996530549578599433858 Again, maths were wrong here, sorry. Correct calculation is: log2(18446744073708551615) = 63.93 > Which is less than the required 64 bits. > > So any filtering operation (e.g. previously generated serial numbers) > actually reduce effective entropy and overall security as illustrated in the > fictional and forced scenario in [2]. > > And finally, we can realize that serial number generation algorithms, among > others requirements, have to be foresee the number of certificates intended > to be generated all along the CA lifetime. > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/mgQaADsCCwAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 > > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, > > not 64. > > > > Can you share how did you get the previous 63.994353?. > > I'm trying the following and I'm getting a different value: > > a = 2^64 = 18446744073709551616 > b = 0x80 = 36028797018963968 > > (a - b) / a * 64 = 63.875 > > Maybe I'm misunderstanding something. Maths were wrong, sorry. I got your same calculation: min = 0100 = 72057594037927936 max = 00 = 18446744073709551615 log2(max - min + 1) = 63.99435343685886 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Open Source CA Software
(Forgot to post it to m.d.s.p) Your right that we all failed to conduct the proper due diligence source code checks on EJBCA and therefore missed this important issue. We all need to learn from this past mistake and implement better checks which prevents issues like this that might arise in the future. Thank you, Burton On Thu, Mar 14, 2019 at 10:57 PM Ryan Sleevi wrote: > > > On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Let's Encrypt CA software 'Boulder' is open source for everyone to browse >> and check for issues. All other CAs should follow the Let's Encrypt lead >> and open source their own CA software for everyone to browse and check for >> issues. We might have found the serial number issue sooner. >> > > Considering EJBCA is open-source, this does not seem that it would > logically follow. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 for us to modify our > > original disclosure to 0 affected certificates. > > "uniqueness and non zero checks" have crippled the effective 64 bit output > from the CSPRNG, so, as I can see it, all of your previously generated serial > numbers (according to the algorithm you disclosed [1]) could be considered > non-compliant to current BRs as explained below: > > First, according to your algorithm, if the MSB in the fully random 8 octets > is 1 you add a leading 00 byte, so until that time you have 64 full bits of > entropy, i.e. 18446744073709551616 possible different values. > > Then, you have to filter out some values. To begin with, you filter out the > value 0, leaving you with 18446744073709551615 possible values. > > Now, you filter the previosly generated serial numbers (known to potential > attackers thanks to current CT deployment), let's say 100 at a given > point in time, so now you are left with 18446744073708551615 possible values. > > And if we do the math: > > 18446744073708551615 / 18446744073709551616 * 64 = > 63.9996530549578599433858 > > Which is less than the required 64 bits. > > So any filtering operation (e.g. previously generated serial numbers) > actually reduce effective entropy and overall security as illustrated in the > fictional and forced scenario in [2]. The most obvious way to implement this is that in case the check fails, you just generate an other serial. You can argue that that new serial will contain 64 bit of entropy, but if you want to be really correct, I think you're right and it doesn't. Just as example, if you generate 64 bit random numbers, and throw away all those that have the top bit set, which would be around half of them, it's easy to see you've reduced it to 63 bit. 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. But I would argue that such an implementation that only generates 64 bits and does the checks is in the spirit of what was intended. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> 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 checks" have crippled the effective 64 bit output from the CSPRNG, so, as I can see it, all of your previously generated serial numbers (according to the algorithm you disclosed [1]) could be considered non-compliant to current BRs as explained below: First, according to your algorithm, if the MSB in the fully random 8 octets is 1 you add a leading 00 byte, so until that time you have 64 full bits of entropy, i.e. 18446744073709551616 possible different values. Then, you have to filter out some values. To begin with, you filter out the value 0, leaving you with 18446744073709551615 possible values. Now, you filter the previosly generated serial numbers (known to potential attackers thanks to current CT deployment), let's say 100 at a given point in time, so now you are left with 18446744073708551615 possible values. And if we do the math: 18446744073708551615 / 18446744073709551616 * 64 = 63.9996530549578599433858 Which is less than the required 64 bits. So any filtering operation (e.g. previously generated serial numbers) actually reduce effective entropy and overall security as illustrated in the fictional and forced scenario in [2]. And finally, we can realize that serial number generation algorithms, among others requirements, have to be foresee the number of certificates intended to be generated all along the CA lifetime. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/S2KNbJSJ-hs/2UIea4fyBgAJ [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/7WuWS_20758/mgQaADsCCwAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Open Source CA Software
On Thu, Mar 14, 2019 at 6:54 PM James Burton via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Let's Encrypt CA software 'Boulder' is open source for everyone to browse > and check for issues. All other CAs should follow the Let's Encrypt lead > and open source their own CA software for everyone to browse and check for > issues. We might have found the serial number issue sooner. > Considering EJBCA is open-source, this does not seem that it would logically follow. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Open Source CA Software
Let's Encrypt CA software 'Boulder' is open source for everyone to browse and check for issues. All other CAs should follow the Let's Encrypt lead and open source their own CA software for everyone to browse and check for issues. We might have found the serial number issue sooner. Thank you, Burton ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 > > GetRandom64Bits(), as described, only returns 63.994353 bits of entropy, > > not 64. > > > > Can you share how did you get the previous 63.994353?. > > I'm trying the following and I'm getting a different value: > > a = 2^64 = 18446744073709551616 > b = 0x80 = 36028797018963968 > > (a - b) / a * 64 = 63.875 > > Maybe I'm misunderstanding something. That post was for after 3/7. We were fine all along. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
> 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. > Can you share how did you get the previous 63.994353?. I'm trying the following and I'm getting a different value: a = 2^64 = 18446744073709551616 b = 0x80 = 36028797018963968 (a - b) / a * 64 = 63.875 Maybe I'm misunderstanding something. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 indicate publicly that > they were compliant with BR 7.1, which zero CAs responded to (I counted them > twice). This means either there are very few CAs bothering with dev-security- > policy, or they're all hunkering down and hoping it'll blow over, which given > that they're going to be forced to potentially carry out mass revocations > would be the game-theoretically sensible approach to take: > > Option 1: Keep quiet case 1 (very likely): -> No-one notices, nothing happens. > Keep quite case 2 (less likely): -> Someone notices, revocation > issues. > Option 2: Say something -> Revocation issues. > > So keeping your head down would be the sensible/best policy. > > Peter. IdenTrust confirms compliance: We do not run EJBCA, and our certificate serial number entropy is greater than what is required from BR 7.1. Marco S. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 to conform to the latest version of the Baseline Requirements. So ISTM that until or unless a CA publicly states that they are non-compliant with BR 7.1, we should act as if that CA has publicly stated that they are compliant with BR 7.1. FWIW though, you can find a public statement from Sectigo at [2]. [1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance [2] https://sectigo.com/blog/all-sectigo-public-certificates-meet-64-bit-serial-number-requirements -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Pre-Incident Report - GoDaddy Serial Number Entropy
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 >> - about 1/2 integers require 8 bytes >> - about 1/512 integers require 7 bytes >> - about 1/131072 integers require 6 bytes >> - about 1/33554432 integers require 5 bytes >> - [...] >> >> That a serial is smaller than 8 bytes is not an indication that it >> doesn't contain enough entropy. > > This is true, but the situation is surely worse - any CA who's serial numbers > do not have a significant length variation is almost certainly not providing > 64 bits of entropy with the exception of those who are add a prefix to ensure > it is positive, and even those are not providing it unless they have lots of > serial numbers with a big block of zeros. > > If any other CA wants to check theirs before someone else does, then now is > surely the time to speak up. Someone else is in the process of checking... ;-) -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Incident Report - Taiwan-CA Invalid SAN
Hello MDSP, Taiwan-CA wants to report an incident about mississued certificates with invalid SAN. Times below are in UTC+8 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. On 2019-03-14, we received an email reporting the problematic certificate. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. 2019-03-12 16:25 The certificate is issued. 2019-03-14 02:25 The incident report is received. 2019-03-14 10:25 The certificate is revoked. 2019-03-14 14:55 We have examined the issuing system and determined the cause of the problem. 2019-03-14 15:34 We have performed an search on unexpired certificates and there’s another revoked certificate with the same problem. 2019-03-14 16:00 We have fixed the bug and planned its deployment to production environment. 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. We have fixed the bug in SAN validation. We will arrange additional check process by reviewing on DNS names manually before the update go live. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. Number of certs: 2 First certificate issued on 2018-05-04 Last certificate issued on 2019-03-12 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. https://crt.sh/?id=439740567 https://crt.sh/?id=1278711906 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. There is a bug in our SAN validation code that some of the DNS names are not properly validated when there are multiple SANs. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. The bug has been fixed and the update will be deployed by 2019-03-30 at the latest. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Pre-Incident Report - GoDaddy Serial Number Entropy
No one wants to paint a target on their back. If I announce we're 100% compliant with everything, that's asking to be shot in the face. You're welcome to look at ours. I think we fully comply with 7.1 (I've double checked everything) and would love to find out if we're not. I like the feedback and research so feel free to peel away at the DigiCert parfait. -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, March 13, 2019 8:03 PM To: Peter Gutmann Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Moore Subject: 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: > > >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 counted them twice). This means either there are very > few CAs bothering with > dev-security- > policy, or they're all hunkering down and hoping it'll blow over, > which given that they're going to be forced to potentially carry out > mass revocations would be the game-theoretically sensible approach to > take: To be fair, this is not an either/or proposition. The third option is that they could be ignoring you specifically, which may not be an unreasonable position, game-theoretically speaking of course. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
