Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

On Sun, Mar 3, 2019 at 5:54 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > Insane that this is even being debated. If the floodgates are opened here
> > you will NOT be able to get things back under control.
> >
>
> While I can appreciate the passion of comments such as this, I think we're
> still back at a core problem:
>
> How can you reconcile this position with the actual program rules &
> guidelines?  If they're declined on some discretionary basis, you loose the
> transparency that's made the Mozilla root program so uniquely valuable.


It is not clear how this follows. As my previous messages tried to capture,
the program is, and has always been, inherently subjective and precisely
designed to support discretionary decisions. These do not seem to
inherently conflict with or contradict transparency.

Even setting aside the examples of inclusions - ones which were designed to
be based on a communal evaluation of risks and benefits - one can look at
the fact that every violation of the program rules and guidelines has not
resulted in CAs being immediately removed. Every aspect of the program,
including the audits, is discretionary in nature.

It would be useful to understand where and how you see the conflict, though.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

On Sun, Mar 3, 2019 at 2:17 PM bxward85--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Insane that this is even being debated. If the floodgates are opened here
> you will NOT be able to get things back under control.
>

While I can appreciate the passion of comments such as this, I think we're
still back at a core problem:

How can you reconcile this position with the actual program rules &
guidelines?  If they're declined on some discretionary basis, you loose the
transparency that's made the Mozilla root program so uniquely valuable.

Other than the relatively minor issues which have already been brought to
light (and presently DarkMatter seems to be contemplating the generation of
a whole new root and issuing heirarchy to address those), where are the
rules violations that would keep them out?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[bxward85--- via dev-security-policy]

On Friday, February 22, 2019 at 2:21:24 PM UTC-7, Wayne Thayer wrote:
> The recent Reuters report on DarkMatter [1] has prompted numerous questions
> about their root inclusion request [2]. The questions that are being raised
> are equally applicable to their current status as a subordinate CA under
> QuoVadis (recently acquired by DigiCert [3]), so it seems appropriate to
> open up a discussion now. The purpose of this discussion is to determine if
> Mozilla should distrust DarkMatter by adding their intermediate CA
> certificates that were signed by QuoVadis to OneCRL, and in turn deny the
> pending root inclusion request.
> 
> The rationale for distrust is that multiple sources [1][4][5] have provided
> credible evidence that spying activities, including use of sophisticated
> targeted surveillance tools, are a key component of DarkMatter’s business,
> and such an organization cannot and should not be trusted by Mozilla. In
> the past Mozilla has taken action against CAs found to have issued MitM
> certificates [6][7]. We are not aware of direct evidence of misused
> certificates in this case. However, the evidence does strongly suggest that
> misuse is likely to occur, if it has not already.
> 
> Mozilla’s Root Store Policy [8] grants us the discretion to take actions
> based on the risk to people who use our products. Despite the lack of
> direct evidence of misissuance by DarkMatter, this may be a time when we
> should use our discretion to act in the interest of individuals who rely on
> our root store.
> 
> I would greatly appreciate everyone's constructive input on this issue.
> 
> - Wayne
> 
> [1] https://www.reuters.com/investigates/special-report/usa-spying-raven/
> 
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1427262
> 
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/hicp7AW8sLA/KUSn20MrDgAJ
> 
> [4]
> https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/
> 
> [5]
> https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/
> 
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/czwlDNbwHXM/Fj-LUvhVQYEJ
> 
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
> [8]
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Insane that this is even being debated. If the floodgates are opened here you 
will NOT be able to get things back under control.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Scott Rea via dev-security-policy]

Thanks Ryan!

Honestly I would prefer things to be clean, but obviously new Root ceremonies 
also come at a significant cost...

I am happy to be guided by Kathleen and Co on this to ensure the community 
standards are maintained without playing favorites.

But if it becomes necessary for the community to consider past incidents while 
considering our case, then it would surely be a service to have such data 
available.

I am very grateful for your offer of assistance, and for the previous data 
points you also provided that gave us a better understanding of community 
consensus that was not apparent from reading the BRs.

Regards,
-Scott

Sent from my iPhone


Scott Rea
Senior Vice President - Trust Services

[cid:image59a03a.PNG@a459c918.459fb124]

Level 15, Aldar HQ
Abu Dhabi, United Arab Emirates
T  +971 2 417 1417
M +971 52 847 5093
E  scott@darkmatter.ae

darkmatter.ae

[Linkedin] [Twitter] 

 [Year of Zayed]  [expo]



The information in this email is intended only for the person(s) or entity to 
whom it is addressed and may contain confidential or privileged information. If 
you receive this email by error, please notify us immediately, delete the 
original message and do not disclose the contents to any other person, use or 
store or copy the information in any medium and for whatever purpose. Any 
unauthorized use is strictly prohibited.

On Mar 3, 2019, at 11:58 PM, Ryan Sleevi 
mailto:r...@sleevi.com>> wrote:

This is a question for Kathleen, as Module Owner.

In the past, CAs which have had BR violations in their root certificates - such 
as negative serial numbers, improper DER encodings, or RFC5280 violations (such 
as keyUsages) - have been required to create new roots before inclusion 
progresses. There have also been a few exceptions, depending on the nature of 
the non-compliance.

Please let me know if it would be helpful to dig up those past incidents for 
such examples.

On Sun, Mar 3, 2019 at 2:47 PM Scott Rea via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
G’day Folks,

we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with the 
latest actions taken by DarkMatter

A question I am posing to this list relates to the trust anchors produced with 
64-bit serial numbers...

A Root certificate is included by explicit trust, and therefore pre-image 
attacks (which is what the increased randomness in serialNumber is meant to 
mitigate) do not apply. As such, is it still necessary to create new Root 
certificates to update serialNumber for submission to Mozilla?

Regards,


--

Scott Rea

On 3/1/19, 8:23 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy" 
mailto:dev-security-policy-boun...@lists.mozilla.org>
 on behalf of 
dev-security-policy@lists.mozilla.org>
 wrote:

Thank you for the detailed incident report Scott. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue,
and attributed it to QuoVadis as the responsible root CA program member.

On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <

dev-security-policy@lists.mozilla.org>
 wrote:

> This incident report relates to the 64-bit serial numbers in all
> certificates that DarkMatter CAs have issued since their inception.  The
> dialog surrounding CABF Ballot 164 “Certificate Serial Number Entropy” was
> unknown to DarkMatter until shared with us recently by Ryan Sleevi of
> Google, and demonstrated to DM that the industry expected at least 64-bits
> of entropy in resulting serialNumbers despite the actual wording of the 
BRs
> Section 7.1.
>
> 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.
>
> A post by Corey Bonnell to the mozilla.dev.security.policy group on
> February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the
> Baseline Requirements and the specific sentence he believed DM was
> violating: “Effective September 30, 2016, CAs SHALL generate 
non-sequential
> Certificate serial numbers greater than zero (0) containing at least 64
> bits of output from a CSPRNG”. Corey also listed 23 certificates (CAs &
> EE’s) and their serialNumbers as evidence. Corey followed this up 2 days
> later with a more comprehensive list that included DMs pre-certs and final
> certs published to various CT Logs.  Corey also pointed out a second issue
> in respect to nameConstrained intermediates issued by Quo Vadis to DM as
> also a potential 

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Ryan Sleevi via dev-security-policy]

This is a question for Kathleen, as Module Owner.

In the past, CAs which have had BR violations in their root certificates -
such as negative serial numbers, improper DER encodings, or RFC5280
violations (such as keyUsages) - have been required to create new roots
before inclusion progresses. There have also been a few exceptions,
depending on the nature of the non-compliance.

Please let me know if it would be helpful to dig up those past incidents
for such examples.

On Sun, Mar 3, 2019 at 2:47 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> G’day Folks,
>
> we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with
> the latest actions taken by DarkMatter
>
> A question I am posing to this list relates to the trust anchors produced
> with 64-bit serial numbers...
>
> A Root certificate is included by explicit trust, and therefore pre-image
> attacks (which is what the increased randomness in serialNumber is meant to
> mitigate) do not apply. As such, is it still necessary to create new Root
> certificates to update serialNumber for submission to Mozilla?
>
> Regards,
>
>
> --
>
> Scott Rea
>
> On 3/1/19, 8:23 PM, "dev-security-policy on behalf of Wayne Thayer via
> dev-security-policy"  behalf of dev-security-policy@lists.mozilla.org> wrote:
>
> Thank you for the detailed incident report Scott. I have created
> https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this
> issue,
> and attributed it to QuoVadis as the responsible root CA program
> member.
>
> On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > This incident report relates to the 64-bit serial numbers in all
> > certificates that DarkMatter CAs have issued since their inception.
> The
> > dialog surrounding CABF Ballot 164 “Certificate Serial Number
> Entropy” was
> > unknown to DarkMatter until shared with us recently by Ryan Sleevi of
> > Google, and demonstrated to DM that the industry expected at least
> 64-bits
> > of entropy in resulting serialNumbers despite the actual wording of
> the BRs
> > Section 7.1.
> >
> > 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.
> >
> > A post by Corey Bonnell to the mozilla.dev.security.policy group on
> > February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1
> of the
> > Baseline Requirements and the specific sentence he believed DM was
> > violating: “Effective September 30, 2016, CAs SHALL generate
> non-sequential
> > Certificate serial numbers greater than zero (0) containing at least
> 64
> > bits of output from a CSPRNG”. Corey also listed 23 certificates
> (CAs &
> > EE’s) and their serialNumbers as evidence. Corey followed this up 2
> days
> > later with a more comprehensive list that included DMs pre-certs and
> final
> > certs published to various CT Logs.  Corey also pointed out a second
> issue
> > in respect to nameConstrained intermediates issued by Quo Vadis to
> DM as
> > also a potential violation, but this shall be dealt with in a
> separate
> > incident report, since DM was not the issuer of these ICAs. Corey’s
> second
> > post was received on the list at 12:50am UAE time February 25, 2019.
> >
> > 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.
> >
> > 29-Apr-16:  DM having previously engaged with QuoVadis for the
> > establishment of a National PKI utilizing a platform and hardware
> that
> > would initially be located in QV DCs, held key ceremonies for
> Private PKIs
> > on EJBCA platform. Platform was configured for random 64-bit
> serialNumbers
> > which at the time was considered far in excess of the then current BR
> > requirement of 20-bit entropy.
> > 30-Apr-16: QV creates DM intermediates intended for issuance of EV
> and OV
> > public trust TLS. These intermediates are instantiated in separate
> > partitions to the DM Private Trust PKIs, but issuance from them is
> still
> > subject to the same platform setting of 64-bit random serialNumbers.
> > 08-Jul-16: CABF Ballot 164 closes and passes. The phrase Corey
> highlighted
> > above is added in place of the previous 20-bit entropy statement.
> > 28-Mar-17: Transition of DM private PKIs and platform to DM DC’s is
> > complete under supervision of EY as WebTrust Auditors. Public Trust
> CAs
> > 

Re: Incident report for DarkMatter CA - change to 128-bit serialNumbers

[Scott Rea via dev-security-policy]

G’day Folks,

we have updated https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 with the 
latest actions taken by DarkMatter

A question I am posing to this list relates to the trust anchors produced with 
64-bit serial numbers...

A Root certificate is included by explicit trust, and therefore pre-image 
attacks (which is what the increased randomness in serialNumber is meant to 
mitigate) do not apply. As such, is it still necessary to create new Root 
certificates to update serialNumber for submission to Mozilla?

Regards,
 

-- 

Scott Rea

On 3/1/19, 8:23 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy"  wrote:

Thank you for the detailed incident report Scott. I have created
https://bugzilla.mozilla.org/show_bug.cgi?id=1531800 to track this issue,
and attributed it to QuoVadis as the responsible root CA program member.

On Thu, Feb 28, 2019 at 4:43 PM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This incident report relates to the 64-bit serial numbers in all
> certificates that DarkMatter CAs have issued since their inception.  The
> dialog surrounding CABF Ballot 164 “Certificate Serial Number Entropy” was
> unknown to DarkMatter until shared with us recently by Ryan Sleevi of
> Google, and demonstrated to DM that the industry expected at least 64-bits
> of entropy in resulting serialNumbers despite the actual wording of the 
BRs
> Section 7.1.
>
> 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.
>
> A post by Corey Bonnell to the mozilla.dev.security.policy group on
> February 23, 2019 at 1:28am UAE time. Corey referenced Section 7.1 of the
> Baseline Requirements and the specific sentence he believed DM was
> violating: “Effective September 30, 2016, CAs SHALL generate 
non-sequential
> Certificate serial numbers greater than zero (0) containing at least 64
> bits of output from a CSPRNG”. Corey also listed 23 certificates (CAs &
> EE’s) and their serialNumbers as evidence. Corey followed this up 2 days
> later with a more comprehensive list that included DMs pre-certs and final
> certs published to various CT Logs.  Corey also pointed out a second issue
> in respect to nameConstrained intermediates issued by Quo Vadis to DM as
> also a potential violation, but this shall be dealt with in a separate
> incident report, since DM was not the issuer of these ICAs. Corey’s second
> post was received on the list at 12:50am UAE time February 25, 2019.
>
> 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.
>
> 29-Apr-16:  DM having previously engaged with QuoVadis for the
> establishment of a National PKI utilizing a platform and hardware that
> would initially be located in QV DCs, held key ceremonies for Private PKIs
> on EJBCA platform. Platform was configured for random 64-bit serialNumbers
> which at the time was considered far in excess of the then current BR
> requirement of 20-bit entropy.
> 30-Apr-16: QV creates DM intermediates intended for issuance of EV and OV
> public trust TLS. These intermediates are instantiated in separate
> partitions to the DM Private Trust PKIs, but issuance from them is still
> subject to the same platform setting of 64-bit random serialNumbers.
> 08-Jul-16: CABF Ballot 164 closes and passes. The phrase Corey highlighted
> above is added in place of the previous 20-bit entropy statement.
> 28-Mar-17: Transition of DM private PKIs and platform to DM DC’s is
> complete under supervision of EY as WebTrust Auditors. Public Trust CAs
> continue to operate out of QV DCs.
> 08-Jun-17: DM Point In Time Audit is complete. NOTE: DM is now responsible
> for platform configuration in compliance with BRs. DM considers current
> serialNumber setting of platform (64-bit SNs) as compliant with BRs 
Section
> 7.1
> 27-Oct-17: DM successfully completes WebTrust Period In Time.
> 04-Nov-17: QV & DM complete transfer of DM public trust intermediates from
> QV to DM under EY & KMPG audit observation
> 18-Dec-17: DM & UAE Roots submitted to Mozilla
> 02-Oct-18: DM successfully completes 2nd WebTrust Audit
> 06-Nov-18: DM submits new WebTrust Audits to Mozilla
> 23-Feb-19: 1:28am: Corey posts to MDSP claiming DM has mis-issuance of
> certs due to BRs Section 7.1
> 23-Feb-19: 3:36am: Post is observed by