Bugzilla

I can only conclude that, despite Comment #4, SSL.com has not, and does not plan, to address the following issues:

* That their system for blocklisting ”expects the SHA256 hash of the modulus.”
  * This is clearly distinct from incorporating `openssl-blacklist`
* They do not plan to develop or support a common baselist of keys, nor have they developed one.
  > We believe it would be to the benefit of the community if there was a common base list for all CAs, as that would prevent similar issues from occurring, at least involving keys in that common list. If we end up independently regenerating the keys included in the openssl-blacklist package, we pledge to share the public part of those keys with the whole community. 
* They they are no longer focused on how:
  > to find a permanent and efficient method of detecting weak Debian keys created by vulnerable versions of OpenSSL in popular architectures, as this seems to be the best way to meet the community's needs.
* That their investigation is complete and they no longer:
  >  intend to share with the community our findings regarding the best solution to extending blacklist databases with more Debian weak keys.
* That they do not plan to share
  > how SSL.com handles RoCA, or other vulnerabilities
  other than a self-attested statement that likely shares the same interpretative issues we see here, that
  > SSL.com also checks for keys that are affected by the ROCA vulnerability
  Without any description that might highlight similar misapplication
* That they have not examined, or do not plan to share how SSL.com handles
  > the use of other data sources, such as the Public Suffix List, referenced in the BRs,

I can only conclude that, despite Comment #4, SSL.com has not, and does not plan, to address the following issues:

* That their system for blocklisting ”expects the SHA256 hash of the modulus.”
  * This is clearly distinct from incorporating `openssl-blacklist`
* They do not plan to develop or support a common baselist of keys, nor have they developed one.
  > We believe it would be to the benefit of the community if there was a common base list for all CAs, as that would prevent similar issues from occurring, at least involving keys in that common list. If we end up independently regenerating the keys included in the openssl-blacklist package, we pledge to share the public part of those keys with the whole community. 
* They they are no longer focused on how:
  > to find a permanent and efficient method of detecting weak Debian keys created by vulnerable versions of OpenSSL in popular architectures, as this seems to be the best way to meet the community's needs.
* That their investigation is complete and they no longer:
  >  intend to share with the community our findings regarding the best solution to extending blacklist databases with more Debian weak keys.
* That they do not plan to share
  > how SSL.com handles RoCA, or other vulnerabilities

  other than a self-attested statement that likely shares the same interpretative issues we see here, that

  > SSL.com also checks for keys that are affected by the ROCA vulnerability

  Without any description that might highlight similar misapplication
* That they have not examined, or do not plan to share how SSL.com handles
  > the use of other data sources, such as the Public Suffix List, referenced in the BRs,