Re: DarkMatter Concerns

[Ryan Sleevi via dev-security-policy]

As Matthew highlights, this is not a new or novel interpretation.

It was introduced in Ballot 164 -
https://cabforum.org/2016/03/31/ballot-164/

The first discussion of this in the CA/B Forum as a Ballot was
https://cabforum.org/pipermail/public/2016-February/006893.html . This
discussion continues through June of that year, when it went to a vote.

During those discussions, there were concerns raised regarding entropy -
which, admittedly, I raised initially, but you can see others sharing
similar concerns. You can also see, however, in the discussions of GUIDs
how those concerns turned out to be well-founded.

Indeed, if you go to April,
https://cabforum.org/pipermail/public/2016-April/007245.html , you can find
discussion about how the maximum legally possible entropy was 159 bits,
precisely for the reason we’re discussing.

While Scott’s proposed language (“entropy”) has problems that the Forum
discussed rather extensively, as to why it would be problematic, the
question of the high but was also discussed during the ballot process. I
believe the conclusion from that discussion was that it would be unlikely
for CAs to rest on exactly 64-bit serials, as they would be able to avoid
any ambiguity or confusion by simply increasing the serial number space
(say, to 65 bits).

Following this ballot, subsequent discussion was had regarding some CAs
that included serials of exactly 64 bits, and how those could not be
compliant.
https://groups.google.com/forum/m/#!msg/mozilla.dev.security.policy/YequotPYLdc/J0K3lUyzBwAJ
is such an example.

On Wed, Feb 27, 2019 at 12:15 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The issue I see with that interpretation is that the very same matter has
> previously been discussed on this list and resolved quite vocally in the
> favor of the other position: that making careful choices about the CSPRNG
> output to conform it to mask out the high order bit makes the output of at
> least that bit not truly the output of the CSPRNG but rather the output of
> the mask.
>
> Pedantically speaking, I actually favor your analysis.  But that probably
> will do you no favors as to public perception at a time point when your
> request for inclusion is at a crucial phase.
>
> On Wed, Feb 27, 2019 at 12:56 AM Scott Rea via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > G’day Wayne et al,
> >
> > I am not sure why members of the group keep making the claim that these
> > certificates are misused under the BRs.
> > Corey pointed to the following paragraph in Section 7.1 of the BRs as the
> > source of the control that DM is accused of not complying with:
> >
> > “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.”
> >
> > DarkMatter has responded to show that we have actually followed this
> > requirement exactly as it is written. Furthermore, since there seems to
> be
> > a number of folks on the Group that believe more stringent controls are
> > needed, DM has agreed to move all its public trust certificates to random
> > serialNumbers with double the required entropy following our next change
> > control in the coming week.
> >
> > It is not a requirement of Section 7.1 that serialNumber contain random
> > numbers with 64-bit entropy – which appears to be the claim you are
> making.
> > If this was the intention of this section in the BRs then perhaps we can
> > propose such a change to the BRs. perhaps something like the following
> > could be proposed:
> >
> > “Effective September 30, 2016, CAs SHALL generate non-sequential
> > Certificate serial numbers greater than zero (0) and output from a CSPRNG
> > such that the resulting serialNumber contains at least 64 bits of
> entropy.”
> >
> > However, once again, I want to reiterate the current practice of DM for
> > the public trust certificates that we have generated to date:
> > 1. all serial numbers are non-sequential;
> > 2. all serial numbers are greater than zero;
> > 3. all serial numbers contain at least 64 bits of output from a CSPRNG
> >
> > As such, all DM certificates that Corey specifically highlighted were
> > issued in compliance with the BRs and specifically in compliance with
> > Section 7.1 that Corey quoted.
> >
> > If there is another requirement in the BRs in respect to serial numbers
> > where it states that they must contain 64 bits of entropy then can you
> > please point this out?
> >
> >
> > Regards,
> >
> > --
> >
> > Scott Rea
> >
> > On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via
> > dev-security-policy"  > behalf of dev-security-policy@lists.mozilla.org> wrote:
> >
> > >I assume you are referring to those certificates containing a serial
> > number with effectively 63-bits of entropy? They are misissued. BR
> > section
> > 4.9.1.1 provides guidance.
> >
> >
> >
> >
> > Scott Rea 

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

The issue I see with that interpretation is that the very same matter has
previously been discussed on this list and resolved quite vocally in the
favor of the other position: that making careful choices about the CSPRNG
output to conform it to mask out the high order bit makes the output of at
least that bit not truly the output of the CSPRNG but rather the output of
the mask.

Pedantically speaking, I actually favor your analysis.  But that probably
will do you no favors as to public perception at a time point when your
request for inclusion is at a crucial phase.

On Wed, Feb 27, 2019 at 12:56 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> G’day Wayne et al,
>
> I am not sure why members of the group keep making the claim that these
> certificates are misused under the BRs.
> Corey pointed to the following paragraph in Section 7.1 of the BRs as the
> source of the control that DM is accused of not complying with:
>
> “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.”
>
> DarkMatter has responded to show that we have actually followed this
> requirement exactly as it is written. Furthermore, since there seems to be
> a number of folks on the Group that believe more stringent controls are
> needed, DM has agreed to move all its public trust certificates to random
> serialNumbers with double the required entropy following our next change
> control in the coming week.
>
> It is not a requirement of Section 7.1 that serialNumber contain random
> numbers with 64-bit entropy – which appears to be the claim you are making.
> If this was the intention of this section in the BRs then perhaps we can
> propose such a change to the BRs. perhaps something like the following
> could be proposed:
>
> “Effective September 30, 2016, CAs SHALL generate non-sequential
> Certificate serial numbers greater than zero (0) and output from a CSPRNG
> such that the resulting serialNumber contains at least 64 bits of entropy.”
>
> However, once again, I want to reiterate the current practice of DM for
> the public trust certificates that we have generated to date:
> 1. all serial numbers are non-sequential;
> 2. all serial numbers are greater than zero;
> 3. all serial numbers contain at least 64 bits of output from a CSPRNG
>
> As such, all DM certificates that Corey specifically highlighted were
> issued in compliance with the BRs and specifically in compliance with
> Section 7.1 that Corey quoted.
>
> If there is another requirement in the BRs in respect to serial numbers
> where it states that they must contain 64 bits of entropy then can you
> please point this out?
>
>
> Regards,
>
> --
>
> Scott Rea
>
> On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via
> dev-security-policy"  behalf of dev-security-policy@lists.mozilla.org> wrote:
>
> >I assume you are referring to those certificates containing a serial
> number with effectively 63-bits of entropy? They are misissued. BR
> section
> 4.9.1.1 provides guidance.
>
>
>
>
> Scott Rea | Senior Vice President - Trust Services
> Tel: +971 2 417 1417 | Mob: +971 52 847 5093
> scott@darkmatter.ae
>
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material. Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender and
> destroy any copies of this information.
>
>
>
>
>
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Wayne et al,

I am not sure why members of the group keep making the claim that these 
certificates are misused under the BRs.
Corey pointed to the following paragraph in Section 7.1 of the BRs as the 
source of the control that DM is accused of not complying with:

“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.”

DarkMatter has responded to show that we have actually followed this 
requirement exactly as it is written. Furthermore, since there seems to be a 
number of folks on the Group that believe more stringent controls are needed, 
DM has agreed to move all its public trust certificates to random serialNumbers 
with double the required entropy following our next change control in the 
coming week.

It is not a requirement of Section 7.1 that serialNumber contain random numbers 
with 64-bit entropy – which appears to be the claim you are making. If this was 
the intention of this section in the BRs then perhaps we can propose such a 
change to the BRs. perhaps something like the following could be proposed:

“Effective September 30, 2016, CAs SHALL generate non-sequential Certificate 
serial numbers greater than zero (0) and output from a CSPRNG such that the 
resulting serialNumber contains at least 64 bits of entropy.”

However, once again, I want to reiterate the current practice of DM for the 
public trust certificates that we have generated to date:
1. all serial numbers are non-sequential;
2. all serial numbers are greater than zero;
3. all serial numbers contain at least 64 bits of output from a CSPRNG

As such, all DM certificates that Corey specifically highlighted were issued in 
compliance with the BRs and specifically in compliance with Section 7.1 that 
Corey quoted.

If there is another requirement in the BRs in respect to serial numbers where 
it states that they must contain 64 bits of entropy then can you please point 
this out?


Regards,

-- 

Scott Rea

On 2/26/19, 7:41 PM, "dev-security-policy on behalf of Wayne Thayer via 
dev-security-policy"  wrote:

>I assume you are referring to those certificates containing a serial
number with effectively 63-bits of entropy? They are misissued. BR section
4.9.1.1 provides guidance.


 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

 






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Peter Gutmann via dev-security-policy]

Mike Kushner via dev-security-policy  
writes:

>EJBCA was possible the first (certainly one of the first) CA products to use
>random serial numbers.

Random serial numbers have been in use for a long, long time, principally to
hide the number of certs a CA was (or wasn't) issuing.  Here's the first one
that came up in my collection, from twenty-five years ago:

  0 551: SEQUENCE {
  4 400:   SEQUENCE {
  8   9: INTEGER 00 A0 98 0F FC 30 AC A1 02
 19  13: SEQUENCE {
 21   9:   OBJECT IDENTIFIER md5WithRSAEncryption (1 2 840 113549 1 1 4)
 32   0:   NULL
   :   }
[...]
 81  43:   SET {
 83  41: SEQUENCE {
 85   3:   OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
 90  34:   PrintableString 'A Free Internet and SET Class 1 CA'
   :   }
   : }
   :   }
126  26: SEQUENCE {
128  11:   UTCTime '960901Z'
   : Error: Time is encoded incorrectly.

RFC 3280 (2002) explicitly added handling for random data as serial numbers:

   Given the uniqueness requirements above, serial numbers can be
   expected to contain long integers.  Certificate users MUST be able to
   handle serialNumber values up to 20 octets. 

(20 bytes being a SHA-1 hash, which was the fashion at the time).

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

>From our side, a validation agent weirdly scoped the domain, saying that the 
>domain was approved using an email to ad...@in-addr.arpa. However, the email 
>clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
>did the validation staff override the domain approval scope and 2) did anyone 
>in validation ever do this before. Once we complete that search, we'll be able 
>to file a bug report and give you more information on what exactly went wrong. 

.arpa is in IANA's root zone per https://www.iana.org/domains/root/db.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the 
email it had an option along the lines of "Authorize in-addr.arpa for all 
orders on account #123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
> rarely has anything other than PTR and NS records defined.
>
> Here this was clearly achieved by creating a CNAME record for 
> 69.168.110.79.in-addr.arpa pointed to cynthia.re .
>
> I've never seen any software or documentation anywhere attempting to 
> utilize a reverse-IP formatted in-addr.arpa address as though it were 
> a normal host name for resolution.  I wonder whether this isn't a case 
> that should just be treated as an invalid domain for purposes of SAN 
> dnsName (like .local).
>
> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>  > wrote:
>
> Thanks Cynthia. We are investigating and will report back shortly.
> 
> From: dev-security-policy
>  > on behalf
> of Cynthia Revström via dev-security-policy
>  >
> Sent: Tuesday, February 26, 2019 12:02:20 PM
> To: dev-security-policy@lists.mozilla.org
> 
> Cc: b...@benjojo.co.uk 
> Subject: Possible DigiCert in-addr.arpa Mis-issuance
>
> Hello dev.security.policy
>
>
> Apologies if I have made any mistakes in how I post, this is my first
> time posting here. Anyway:
>
>
> I have managed to issue a certificate with a FQDN in the SAN that I do
> not have control of via Digicert.
>
>
> The precert is here: https://crt.sh/?id=1231411316
>
> SHA256:
> 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1
>
>
> I have notified Digicert who responded back with a generic response
> followed by the certificate being revoked through OCSP. However I
> believe that this should be wider investigated, since this cert was
> issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
> that I do control though reverse DNS.
>
>
> When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
> that the whole of in-addr.arpa became validated on my account, instead
> of just my small section of it (168.110.79.in-addr.arpa at best).
>
>
> To test if digicert had just in fact mis-validated a FQDN, I
> tested with
> the reverse DNS address of 192.168.1.1, and it worked and Digicert
> issued me a certificate with 1.1.168.192.in-addr.arpa on it.
>
>
> Is there anything else dev.security.policy needs to do with this? This
> seems like a clear case of mis issuance. It's also not clear if
> in-addr.arpa should even be issuable.
>
>
> I would like to take a moment to thank Ben Cartwright-Cox and
> igloo5
> in pointing out this violation.
>
>
> Regards
>
> Cynthia Revström
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> 
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> 

Re: DarkMatter Concerns

[Matthew Hardeman via dev-security-policy]

I'd like to take a moment to point out that determination of the beneficial
ownership of business of various sorts (including CAs) can, in quite a
number of jurisdictions, be difficult to impossible (short of initiating
adverse legal proceedings) to determine.

What does this mean for Mozilla's trusted root program or any other root
program for that matter?  I submit that it means that anyone rarely knows
to a certainty the nature and extent of ownership and control over a given
business to a high degree of confidence.  This is especially true when you
start divorcing equity interest from right of control.  (Famous example,
Zuckerberg's overall ownership of Facebook is noted at less than 30% of the
company, yet he ultimately has personal control of more than 70% of voting
rights over the company, the end result is that he ultimately can control
the company and its operations in virtually any respect.)

A number of jurisdictions allow for creating of trusts, etc, for which the
ownership and control information is not made public.  Several of those, in
turn, can each be owners of an otherwise normal looking LLC in an innocuous
jurisdiction elsewhere, each holding say, 10% equity and voting rights.
Say there are 6 of those.  Well, all six of them can ultimately be proxies
for the same hidden partner or entity.  And that partner/entity would
secretly be in full control.  Without insider help, it would be very
difficult to determine who that hidden party is.

Having said all of this, I do have a point relevant to the current case.
Any entity already operating a WebPKI trusted root signed SubCA should be
presumed to have all the access to the professionals and capital needed to
create a new CA operation with cleverly obscured ownership and corporate
governance.  You probably can not "fix" this via any mechanism.

In a sense, that DarkMatter isn't trying to create a new CA out of the
blue, operated and controlled by them or their ultimate ownership but
rather is being transparent about who they are is interesting.

One presumes they would expect to get caught at misissuance.  The record of
noncompliance and misissuance bugs created, investigated, and resolved one
way or another demonstrates quite clearly that over the history of the
program a non-compliant CA has never been more likely to get caught and
dealt with than they are today.

I believe the root programs should require a list of human names with
verifiable identities and corresponding signed declarations of all
management and technical staff with privileged access to keys or ability to
process signing transactions outside the normal flow.  Each of those people
should agree to a life-long ban from trusted CAs should they be shown to
take intentional action to produce certificates which would violate the
rules, lead to MITM, etc.  Those people should get a free pass if they
whistle blow immediately upon being forced, or ideally immediately
beforehand as they hand privilege and control to someone else.

While it is unreasonable to expect to be able to track beneficial
ownership, formal commitments from the entity and the individuals involved
in day to day management and operations would lead to a strong assertion of
accountable individuals whose cooperation would be required in order to
create/provide a bad certificate.  And those individuals could have "skin
in the game" -- the threat of never again being able to work for any CA
that wants to remain in the trusted root programs.

All of Google, Amazon, and Microsoft are in the program.  All of these have
or had significant business with at least the US DOD and have a significant
core of managing executives as well as operations staff and assets in the
United States.  As such, it is beyond dispute that each of these is
subordinate to the laws and demands of the US Government.  Still, none of
these stand accused of using their publicly trusted root CAs to issue
certificates to a nefarious end.  It seems that no one can demonstrate that
DarkMatter has or would either.  If so, no one has provided any evidence of
that here.

It's beyond dispute that Mozilla's trusted root program rules allow for
discretionary exclusion of a participant without cause.  As far as I'm
aware, that hasn't been relied upon as yet.

For technologists and logicians, it should rankle that it might be
necessary to make reliance upon such a provision in order to keep
DarkMatter out.  In my mind, it actually calls into question whether they
should be kept out.

As Digicert's representative has already pointed out, the only BR
compliance matter even suggested at this point is the bits-of-entropy in
serial number issue and others have been given a pass on that.  While I
suppose you could call this exclusionary and sufficient to prevent the
addition, it would normally be possible for them to create new key pairs
and issuance hierarchy and start again with an inclusion request for those,
avoiding that concern in round 2.

I think the 

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.


It was just that I just tried to get a cert for my domain for a test to 
see if that would be issued.


And upon verifying the domain via email, I saw that on the page linked 
in the email it had an option along the lines of "Authorize in-addr.arpa 
for all orders on account #123456" (not that exact text but the same 
meaning).


Now I am not sure if this would work, but I suspect if for example I got 
DNS control over cynthia.site.google.com, I could get a cert for 
google.com if this is a systemic issue and not just a one off.


- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
rarely has anything other than PTR and NS records defined.


Here this was clearly achieved by creating a CNAME record for 
69.168.110.79.in-addr.arpa pointed to cynthia.re .


I've never seen any software or documentation anywhere attempting to 
utilize a reverse-IP formatted in-addr.arpa address as though it were 
a normal host name for resolution.  I wonder whether this isn't a case 
that should just be treated as an invalid domain for purposes of SAN 
dnsName (like .local).


On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
> wrote:


Thanks Cynthia. We are investigating and will report back shortly.

From: dev-security-policy
mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
of Cynthia Revström via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org

Cc: b...@benjojo.co.uk 
Subject: Possible DigiCert in-addr.arpa Mis-issuance

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:


I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.


The precert is here: https://crt.sh/?id=1231411316

SHA256:
651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response
followed by the certificate being revoked through OCSP. However I
believe that this should be wider investigated, since this cert was
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
that I do control though reverse DNS.


When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
that the whole of in-addr.arpa became validated on my account, instead
of just my small section of it (168.110.79.in-addr.arpa at best).


To test if digicert had just in fact mis-validated a FQDN, I
tested with
the reverse DNS address of 192.168.1.1, and it worked and Digicert
issued me a certificate with 1.1.168.192.in-addr.arpa on it.


Is there anything else dev.security.policy needs to do with this? This
seems like a clear case of mis issuance. It's also not clear if
in-addr.arpa should even be issuable.


I would like to take a moment to thank Ben Cartwright-Cox and
igloo5
in pointing out this violation.


Regards

Cynthia Revström

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Matthew Hardeman via dev-security-policy]

Is it even proper to have a SAN dnsName in in-addr.arpa ever?

While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it rarely
has anything other than PTR and NS records defined.

Here this was clearly achieved by creating a CNAME record for
69.168.110.79.in-addr.arpa pointed to cynthia.re.

I've never seen any software or documentation anywhere attempting to
utilize a reverse-IP formatted in-addr.arpa address as though it were a
normal host name for resolution.  I wonder whether this isn't a case that
should just be treated as an invalid domain for purposes of SAN dnsName
(like .local).

On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Thanks Cynthia. We are investigating and will report back shortly.
> 
> From: dev-security-policy 
> on behalf of Cynthia Revström via dev-security-policy <
> dev-security-policy@lists.mozilla.org>
> Sent: Tuesday, February 26, 2019 12:02:20 PM
> To: dev-security-policy@lists.mozilla.org
> Cc: b...@benjojo.co.uk
> Subject: Possible DigiCert in-addr.arpa Mis-issuance
>
> Hello dev.security.policy
>
>
> Apologies if I have made any mistakes in how I post, this is my first
> time posting here. Anyway:
>
>
> I have managed to issue a certificate with a FQDN in the SAN that I do
> not have control of via Digicert.
>
>
> The precert is here: https://crt.sh/?id=1231411316
>
> SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1
>
>
> I have notified Digicert who responded back with a generic response
> followed by the certificate being revoked through OCSP. However I
> believe that this should be wider investigated, since this cert was
> issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
> that I do control though reverse DNS.
>
>
> When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
> that the whole of in-addr.arpa became validated on my account, instead
> of just my small section of it (168.110.79.in-addr.arpa at best).
>
>
> To test if digicert had just in fact mis-validated a FQDN, I tested with
> the reverse DNS address of 192.168.1.1, and it worked and Digicert
> issued me a certificate with 1.1.168.192.in-addr.arpa on it.
>
>
> Is there anything else dev.security.policy needs to do with this? This
> seems like a clear case of mis issuance. It's also not clear if
> in-addr.arpa should even be issuable.
>
>
> I would like to take a moment to thank Ben Cartwright-Cox and igloo5
> in pointing out this violation.
>
>
> Regards
>
> Cynthia Revström
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[hackurx--- via dev-security-policy]

Le mardi 26 février 2019 16:35:11 UTC+1, Hanno Böck a écrit :
> This statement repeats the claim that you wrote here previously,
> specifically:
> "I want to assure you that DarkMatter's work is solely focused on
> defensive cyber security, secure communications and digital
> transformation."
> 
> The statement does not comment on the Reuters article, but it is in
> stark contradiction to it, as it clearly describes "offensive cyber"
> operations by Dark Matter.
> 
> I find it very hard to believe that the entire Reuters story is a hoax.
> Nobdody has challenged it yet. According to the Reuters article
> DarkMatter was asked for a comment and didn't reply.
> 
> Either the Reuters story is false or your CEOs statement is false. They
> can't both be true.
> 
> 
> -- 
> Hanno Böck
> https://hboeck.de/

It reminds me of a similar story in my country:
https://security.googleblog.com/2013/12/further-improving-digital-certificate.html

Please add a strict limit to the top-level domains in Firefox...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Thanks Cynthia. We are investigating and will report back shortly.

From: dev-security-policy  on 
behalf of Cynthia Revström via dev-security-policy 

Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org
Cc: b...@benjojo.co.uk
Subject: Possible DigiCert in-addr.arpa Mis-issuance

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:


I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.


The precert is here: https://crt.sh/?id=1231411316

SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response
followed by the certificate being revoked through OCSP. However I
believe that this should be wider investigated, since this cert was
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
that I do control though reverse DNS.


When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
that the whole of in-addr.arpa became validated on my account, instead
of just my small section of it (168.110.79.in-addr.arpa at best).


To test if digicert had just in fact mis-validated a FQDN, I tested with
the reverse DNS address of 192.168.1.1, and it worked and Digicert
issued me a certificate with 1.1.168.192.in-addr.arpa on it.


Is there anything else dev.security.policy needs to do with this? This
seems like a clear case of mis issuance. It's also not clear if
in-addr.arpa should even be issuable.


I would like to take a moment to thank Ben Cartwright-Cox and igloo5
in pointing out this violation.


Regards

Cynthia Revström

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Possible DigiCert in-addr.arpa Mis-issuance

[Cynthia Revström via dev-security-policy]

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first 
time posting here. Anyway:



I have managed to issue a certificate with a FQDN in the SAN that I do 
not have control of via Digicert.



The precert is here: https://crt.sh/?id=1231411316

SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response 
followed by the certificate being revoked through OCSP. However I 
believe that this should be wider investigated, since this cert was 
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area 
that I do control though reverse DNS.



When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed 
that the whole of in-addr.arpa became validated on my account, instead 
of just my small section of it (168.110.79.in-addr.arpa at best).



To test if digicert had just in fact mis-validated a FQDN, I tested with 
the reverse DNS address of 192.168.1.1, and it worked and Digicert 
issued me a certificate with 1.1.168.192.in-addr.arpa on it.



Is there anything else dev.security.policy needs to do with this? This 
seems like a clear case of mis issuance. It's also not clear if 
in-addr.arpa should even be issuable.



I would like to take a moment to thank Ben Cartwright-Cox and igloo5 
in pointing out this violation.



Regards

Cynthia Revström

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: T-Systems invalid SANs

[Wayne Thayer via dev-security-policy]

Thank you. I have created a bug and requested a response from T-Systems:
https://bugzilla.mozilla.org/show_bug.cgi?id=1530718

- Wayne

On Tue, Feb 26, 2019 at 8:07 AM michel.lebihan2000--- via
dev-security-policy  wrote:

> Hello,
>
> While looking at CT logs, I noticed multiple certificates issued by
> T-Systems that have SANs that seem invalid. The first certificate I noticed
> is https://crt.sh/?id=1044575692=ocsp,cablint,zlint The DNS name has
> a leading /. That certificate was revoked, but I didn't see any report
> about this on this list. Other certificates I noticed are
> https://crt.sh/?id=1003197184=cablint,zlint where the CN has a
> leading whitespace and the SAN is double. This one has also been revoked.
>
> Other certificates that seem mississued are:
> https://crt.sh/?id=1044697381=cablint,zlint
> https://crt.sh/?id=282646160=cablint,zlint
>
> They are all revoked.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Matthew Finkel via dev-security-policy]

On Sat, Feb 23, 2019 at 06:51:11AM -0800, alex.gaynor--- via 
dev-security-policy wrote:
> (Writing in my personal capacity)

I'm writing in my personal capacity, as much as possible, as well (I am
a Tor/Tor Browser developer).

> 
> One of the things that I think is important is to tease out factual 
> predicates that could be grounds for exclusion.
[...]
> 
> First, is honesty. Even as we build technologies such as CT and audit regimes 
> which improve auditability and accountability, CAs are ultimately in the 
> business of trust. https://twitter.com/josephfcox/status/1090592247379361792 
> makes the argument that DarkMatter has been in the business of lying to 
> journalists. Lying is fundamentally incompatible with trust.
> 

A phrase I've seen used repeatedly with regard to CAs is they must
operate "beyond reproach", Ryan Sleevi has used this phrase more times
than I can remember since I began following this mailing list (and CA/B
discussions, in general). Certificate Authorities are placed in a unique
position of trust on the Internet, and this trust must not be given
easily. I appreciate this community's attempts at holding the CAs
accountable for their errors, thank you.

Cooper described the process of Root Certificate Inclusion as technical
and bureaucratic. If a CA reaches BR compliance, then it shows some
technical competence, but is that enough? This achievement presents no
evidence of trustworthiness. That (trustworthiness) comes from ones
reputation. As Alex, and others, mentioned, DarkMatter have a bad
reputation when it comes to honesty and they are not a trusted
organization.

In addition, DarkMatter assert all of their public trust EV and OV TLS
certificates are included in Certificate Transparency logs. Again this
is a necessary step in achieving a reputation of being trustable, but by
no means is it sufficient (DV certificates should be logged, as well, at
a minimum). Regardless, Certificate Transparency only helps at
post-compromise - it does not protect the user who was affected. We
should not sacrifice one user for the greater good. Similary, DigiCert
"[...] do not revoke certificates based purely on allegations of
wrongdoing". This is understandable from a business and legal
perspective, but not from the perspective of maintaining trust and
protecting end-users from possible harm. Any direct evidence of
intentional misissuance will be too late.

The risk of misuse cannot be ignored even if we believe these root
certificates are currently only used within their National PKI as a
"national authentication and digital signing platform". There is a
significant conflict of interest within DarkMatter. Based on that
mounting evidence detailing their secret, offensive exploitation
department (read defensive cyber security), their operation as a CA is
absolutely reproachable and this sets an awful precedent. This holds
true for their current intermediate, as well.

Jeopardizing the security, safety, and privacy of Internet users because
we don't have any publicly-known, direct evidence, of DarkMatter
misusing their intermediate CA doesn't help me sleep at night. They are
not a trusted entity, and they should not be treated as if they are
trusted. Period. Mozilla should use their discretion and protect their
users.

Thanks,
Matt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Richard Salz via dev-security-policy]

Thanks for the clarification.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Wayne Thayer via dev-security-policy]

Scott,

On Tue, Feb 26, 2019 at 3:21 AM Scott Rea via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> G’day folks,
>
> we appreciate the many suggestions made on the list to strengthen the
> entropy of random serialNumbers.
>
> One challenge we face currently is that our platform (which does support
> higher entropy) but only supports this at a global level. So if we make a
> global change, then ALL our CAs will use the larger serialNumbers and this
> would have an impact for example on CAs which are in completely different
> hierarchies to those used for Public Trust to have to also adopt the change
> (and for CA’s used for constrained environments e.g. IoT, the size of each
> extension has an impact).
>
> However, we have been working with our platform provider and can now
> report that effective beginning of next week, DarkMatter will move to using
> random 128-bit serial numbers for all our Public Trust certificates.
>
> The remaining question is what should be done if anything about existing
> certificates with 64-bit serialNumbers?
>
> I assume you are referring to those certificates containing a serial
number with effectively 63-bits of entropy? They are misissued. BR section
4.9.1.1 provides guidance.

Mozilla provides further guidance here:
https://wiki.mozilla.org/CA/Responding_To_An_Incident
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Hanno Böck via dev-security-policy]

This statement repeats the claim that you wrote here previously,
specifically:
"I want to assure you that DarkMatter's work is solely focused on
defensive cyber security, secure communications and digital
transformation."

The statement does not comment on the Reuters article, but it is in
stark contradiction to it, as it clearly describes "offensive cyber"
operations by Dark Matter.

I find it very hard to believe that the entire Reuters story is a hoax.
Nobdody has challenged it yet. According to the Reuters article
DarkMatter was asked for a comment and didn't reply.

Either the Reuters story is false or your CEOs statement is false. They
can't both be true.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Paul Wouters via dev-security-policy]

On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote:


Hi Scott.  It seems that the m.d.s.p list server stripped the
attachment, but (for the benefit of everyone reading this) I note that
you've also attached it to
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.

Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699


Thanks for sending the link. The letter is uhm interesting. It both
states they cannot say anything for national security reasons, say they
unconditionally comply with national security (implying even if that
violates any BRs) and claims transparency for using CT which is in fact
being forced by browser vendors on them.

"quests to protect their nations" definitely does not exclude "issuing
BR violating improper certificates to ensnare enemies of a particular
nation state".

Now of course, I don't think this is very different from US based
companies that are forced to do the same by their governments, which
is why DNSSEC TLSA can be trusted more (and monitored better) than a
collection of 500+ CAs from all main nation states that are known for
offense cyber capabilities. But you can ignore this as off-topic :)

Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Jonathan Rudenberg via dev-security-policy]

On Tue, Feb 26, 2019, at 10:06, Scott Rea via dev-security-policy wrote:
> G’day Folks,
> 
> DarkMatter CEO (Karim Sabbagh), has provided an official response to 
> Mozilla on the recent media article about the UAE that referenced 
> security and intelligence matters. Per Wayne’s request to potentially 
> share this on the list, I am attaching a copy of that letter to this 
> post.

Since attachments tend to not come through on this list, here's a link: 
https://bugzilla.mozilla.org/attachment.cgi?id=9046699

This statement does not appear to me to directly deny any of the media reports, 
it simply calls them "misleading". There is no  standard definition for 
"defensive cyber activities", which could mean a lot of things.

As far as I know DarkMatter has not provided a comment directly to Reuters at 
all, let alone denied the report.

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Rob Stradling via dev-security-policy]

Hi Scott.  It seems that the m.d.s.p list server stripped the 
attachment, but (for the benefit of everyone reading this) I note that 
you've also attached it to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1427262.

Direct link:
https://bug1427262.bmoattachments.org/attachment.cgi?id=9046699

On 26/02/2019 13:56, Scott Rea via dev-security-policy wrote:
> G’day Folks,
> 
> DarkMatter CEO (Karim Sabbagh), has provided an official response to Mozilla 
> on the recent media article about the UAE that referenced security and 
> intelligence matters. Per Wayne’s request to potentially share this on the 
> list, I am attaching a copy of that letter to this post.
> 
> Regards,
>   
> 

-- 
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: DarkMatter Concerns

[Richard Salz via dev-security-policy]

So then every cert signed by the keys intended for the trust store will be
CT logged?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

T-Systems invalid SANs

[michel.lebihan2000--- via dev-security-policy]

Hello,

While looking at CT logs, I noticed multiple certificates issued by T-Systems 
that have SANs that seem invalid. The first certificate I noticed is 
https://crt.sh/?id=1044575692=ocsp,cablint,zlint The DNS name has a leading 
/. That certificate was revoked, but I didn't see any report about this on this 
list. Other certificates I noticed are 
https://crt.sh/?id=1003197184=cablint,zlint where the CN has a leading 
whitespace and the SAN is double. This one has also been revoked.

Other certificates that seem mississued are:
https://crt.sh/?id=1044697381=cablint,zlint
https://crt.sh/?id=282646160=cablint,zlint

They are all revoked.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Mike Kushner via dev-security-policy]

Hi,

Since EJBCA as a product was mentioned we thought we could chime in with some 
background and updates.

EJBCA was possible the first (certainly one of the first) CA products to use 
random serial numbers. From the very beginning, 64 bit random serial numbers, 
from a CSPRNG, were used. This was back in the days when the opinion was that 
sequential serial numbers had to be used. We had some work convincing some 
users that random was better than sequential. By default 8 bytes (64 bits) were 
used, as it's a nice power of 2 number. Back then longer serial numbers were 
frowned upon and there were product out there that could not even parse 16 byte 
serial numbers, so 8 bytes was a good choice that was compatible.
As years went by we introduced the possibility to use longer serial numbers, 
through a configuration setting at build time. This setting is no convenient to 
use (automatically persisted across upgrades etc) in our Appliance and cloud 
platforms, and we had on the roadmap to remedy this with a more use friendly 
setting.

A very strong goal of EJBCA, and PrimeKey, is to be standard compliant with 
both open standards and regulations, and thus we are not completely satisfied 
with debating 63 vs 64 bits.
We are planning to release a fix version with a convenient per CA setting, and 
default to larger serials, in short time. Any existing CA will be easily 
configured to use between 4 and 20 octets serial numbers for future issuance. 
Serial numbers must be compliant with RFC5280 and X.690, which is the test we 
do on the output from the CSPRNG, only using compliant ones.
https://jira.primekey.se/browse/ECA-4991

In addition to random serial numbers, EJBCA checks for collisions, so even in 
the very unlikely event of equal serial numbers being generated, no 
certificates with duplicated serial numbers should be issued from a CA based on 
the EJBCA software. By comparison, collisions do happen regularly in testing 
when using 32 bit serial numbers (and are averted), so the underlying checks 
function as we expect. 

Looking back at the origin to when public CAs moved form sequential to random 
serial numbers we believe this originated from the weakness in SHA1, making a 
preimage attack at least theoretically possible against SHA1. EJBCA was very 
early on supporting SHA256 as well. To our knowledge there are no known 
preimage attacks against SHA256, correct us if we're wrong. In other words, we 
do not consider this a security issue, but (only) a compliance issue.

Cheers,
Tomas Gustafsson (CTO)
and 
Mike Agrenius Kushner (PO EJBCA)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Folks,

DarkMatter CEO (Karim Sabbagh), has provided an official response to Mozilla on 
the recent media article about the UAE that referenced security and 
intelligence matters. Per Wayne’s request to potentially share this on the 
list, I am attaching a copy of that letter to this post.

Regards,
 
-- 
Scott Rea

 

 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

 






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Rich,

This is correct with one qualification – every TLS cert chained to the 
submitted Roots are CT logged. The exception is that we also issue Public Trust 
client certificates (through a separate Issuing CA) and these are not required 
to be logged. From memory, our EV’s currently go to 4 different logs, and OVs 
got to 3 different logs. We don’t do DV at this time.

Regards,

--
Scott Rea


Scott Rea
Senior Vice President - Trust Services

[cid:image447aa1.PNG@2f49b9ba.4485a5f4]

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.

From: Richard Salz 
Date: Tuesday, February 26, 2019 at 5:31 PM
To: Scott Rea 
Cc: 
Subject: Re: DarkMatter Concerns

So then every cert signed by the keys intended for the trust store will be CT 
logged?

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day Rich,

DM has submitted Roots intended for Public Trust to Mozilla and other browser 
operators, but we also operate private trust PKIs under separate anchors. These 
private PKIs also issue certificates to secure TLS in closed environments, but 
Private Roots are not in public CT Logs and therefore these private TLS certs 
are not logged.

Regards,
 

-- 

Scott Rea

On 2/25/19, 9:59 PM, "dev-security-policy on behalf of rich.salz--- via 
dev-security-policy"  wrote:

Apart from the concerns others have already raised, I am bothered by the 
wording of one of the Dark Matter commitments, which says that "TLS certs 
intended for public trust" will be logged. What does public trust mean?  Does 
it include certificates intended only for use within their country? Those 
intended to be used only on a small, privately-specified, set of recipients?

Perhaps a better way to phrase my question is: what certs would DM issue 
that would *not* be subject to their CT logging SOP?

Is there any other trusted root that has made a similar exemption?
 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



 






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DarkMatter Concerns

[Scott Rea via dev-security-policy]

G’day folks,

we appreciate the many suggestions made on the list to strengthen the entropy 
of random serialNumbers.

One challenge we face currently is that our platform (which does support higher 
entropy) but only supports this at a global level. So if we make a global 
change, then ALL our CAs will use the larger serialNumbers and this would have 
an impact for example on CAs which are in completely different hierarchies to 
those used for Public Trust to have to also adopt the change (and for CA’s used 
for constrained environments e.g. IoT, the size of each extension has an 
impact).

However, we have been working with our platform provider and can now report 
that effective beginning of next week, DarkMatter will move to using random 
128-bit serial numbers for all our Public Trust certificates. 

The remaining question is what should be done if anything about existing 
certificates with 64-bit serialNumbers?  



Regards,
 

-- 

Scott Rea

On 2/25/19, 7:51 PM, "dev-security-policy on behalf of Tim Shirley via 
dev-security-policy"  wrote:

There are other ways to achieve a guarantee of non-collision besides 
re-generating.  For example, we incorporate the timestamp of issuance into the 
serial number alongside the random bits.  You could also incorporate a 
sequential value into your serial number.  Both methods serve to guarantee 
that, even in the extremely unlikely event that you duplicate the random 
component of your serial number in 2 different certificates, you still have 2 
different serial numbers.

But at least 64 bits of whatever is produced needs to be entropy, and if 
any "acceptability test" is applied after the random value is generated and 
actually rejects a value, then you've reduced your number of effective bits of 
entropy.  From what has been described here, it seem clear that in this case 
what's actually being generated is 63 bits of entropy.  Any process truly 
generating 64 bits of entropy should be producing serial numbers with 9 octets 
~50% of the time.

Regards,
 
Tim Shirley  
Software Architect  
t: +1 412.395.2234 
 
www.securetrust.com  
 
Introducing the Global Compliance Intelligence Report 

 
 

On 2/25/19, 3:58 AM, "dev-security-policy on behalf of Scott Rea via 
dev-security-policy"  wrote:

I think it reasonable to expect that EVERY implementation of a 
compliant CA software is doing this post-processing to ensure the intended 
serialNumber has not already been used, and this is not something unique to 
EJBCA. As such, every CA out there will have some process that requires 
post-processing of whatever value is returned with a possibility to have to 
repeat the process if there is a collision.

 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 417 1417 | Mob: +971 52 847 5093
scott@darkmatter.ae

The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited. If you received this 
in error, please contact the sender and destroy any copies of this information.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



 






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy