Re: DarkMatter Concerns
On 2/24/19 11:08 AM, Nex wrote: > On 2/23/19 11:07 AM, Scott Rea via dev-security-policy wrote: >> G’day Wayne et al, >> >> In response to your post overnight (included below), I want to assure you >> that DarkMatter’s work is solely focused on defensive cyber security, secure >> communications and digital transformation. We have never, nor will we ever, >> operate or manage non-defensive cyber activities against any nationality. >> >> Furthermore, in the spirit of transparency, we have published all our public >> trust TLS certificates to appropriate CT log facilities (including even all >> our OV certificates) before this was even a requirement. We have been >> entirely transparent in our operations and with our clients as we consider >> this a vital component of establishing and maintaining trust. >> >> We have used FIPS certified HSMs as our source of randomness in creating our >> Authority certificates, so we have opened an investigation based on Corey >> Bonnell’s earlier post regarding serial numbers and will produce a >> corresponding bug report on the findings. >> >> I trust this answers your concerns and we can continue the Root inclusion >> onboarding process. > > For clarity, are you rejecting all of the following articles and blog > posts as false and fabricated? > > 1. https://www.reuters.com/investigates/special-report/usa-spying-raven/ > 2. > https://theintercept.com/2016/10/24/darkmatter-united-arab-emirates-spies-for-hire/ > 3. > https://www.evilsocket.net/2016/07/27/How-The-United-Arab-Emirates-Intelligence-Tried-to-Hire-me-to-Spy-on-its-People/ The New York Times just published another investigative report that mentions DarkMatter at length, with additional testimonies going on the record: 4. https://www.nytimes.com/2019/03/21/us/politics/government-hackers-nso-darkmatter.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Pre-Incident Report - Buypass certificates noncompliant with BR 7.1
We are aware that Buypass is on the list of CAs that have been noncompliant with BR 7.1. We will send an Incident Report within the next few days. Regards Mads ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Questions about Mozilla Root Store Policy 5.1
Hi I have few questions about Mozilla Root Store Policy 5.1 Mozilla Root Store Policy 5.1 only permits following algorithms for ECC. > 5.1 Algorithms > > Root certificates in our root program, and __any certificate__ which > chains up to them, __MUST__ use __only__ algorithms and key sizes from the > following set: > > RSA keys whose modulus size in bits is divisible by 8, and is at least > 2048. > Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512. > ECDSA keys using one of the following curve-hash pairs: > P-256 with SHA-256 > P-384 with SHA-384 I am wondering the above is for validation path only, or also for usage of EE certificate. #I thought it might be also for EE cert, since RFC5480 does not require anything on key usage(I descrive detail at the bottom of this text). As far as I understand, ECDSA public key just show a point on elliptic curve. that point can also be used (plain)ECDH or ECIES. So, if 5.1's description is also for end entity cert, EE cert's key-usage must contain digitalSignature, can contain nonRepudiation, and must not contain key agreement, key encipherment, etc. to comply 5.1. (question.1) So far I guess, that statement of 5.1 include requirement for key-usage of any EE certs, not limit to server certificates. is it correct? (question.2) In addition, if CA issue ECC certificate without appropriate key-usage, reason to revoke can be non-compliance with Mozilla's root program? RFC 5480 does not seems to require anything for key-usage #since, RFC 2119 state MAY is "truely optional" > RFC 5480ECC SubjectPublicKeyInfo Format March 2009 > >If the keyUsage extension is present in an End Entity (EE) >certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, >then any combination of the following values MAY be present: > > digitalSignature; > nonRepudiation; and > keyAgreement. Regards Tadahiko Ito ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
