RE: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

One other thing I wanted to get ahead of is that we are revoking three Dark
Matter issuing CAs tomorrow. This revocation was planned well before this
discussion started. These three certificates were issued in 2016 with
improper name constraints.  The 2017 certificates currently used are
replacements for those certificates without any name constraints. The three
certificates are:

CN=DarkMatter Assured CA,O=DarkMatter LLC,C=AE
4812bd923ca8c43906e7306d2796e6a4cf222e7d2024-04-29 22:53:00
6b6fa65b1bdc2a0f3a7e66b590f93297b8eb56b9
CN=DarkMatter High Assurance CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c8362024-04-29 22:38:11
8835437d387bbb1b58ff5a0ff8d003d8fe04aed4
CN=DarkMatter Secure CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c8362024-04-29 22:45:18
6a2c691767c2f1999b8c020cbab44756a99a0c41

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, February 25, 2019 1:43 PM
To: Buschart, Rufus ;
mozilla-dev-security-policy 
Subject: RE: DarkMatter Concerns

Hi all,

Sorry for the delayed response. Been traveling and haven't had a chance to
properly format my thoughts until now. 

As you all know, DigiCert recently acquired the Quovadis CA. As the operator
of the CA, DigiCert is responsible for the issuing CA controlled by
DarkMatter. DarkMatter controls the keys of the intermediate, have their own
CPS, and undergo their own annual audits. 

With one exception, DigiCert has a policy against signing externally
operated intermediate CAs capable of issuing TLS certificates. The exception
is for browser operators who want a cross-sign, which is not applicable in
this case. We've found that limiting external CAs provides a better
situation for users and the security community. As we've done in the past,
we feel there is a logical and legal way to address inherited contracts and
externally operating CAs so that we do not leave site operators and relying
parties using those sites in a lurch. We are committed to working with
DarkMatter on a plan that works for them and aligns to our policy.

As for DarkMatter, we have not received direct evidence of any intentional
mis-issuance or use of a certificate for a MiTM attack. As a policy, we do
not revoke certificates based purely on allegations of wrongdoing.  This is
true regardless of source, such as trademark disputes, government requests
for revocation, and similar matters. We do revoke certificates after
receiving a formal request for revocation from a trust store operator. I
think this policy is a logical approach as the policy avoids government
influence and public pressure over unpopular sites while acknowledging the
browser's control over their root store.

If we are presented with direct evidence of serious BR violations or
wrongdoing, we will certainly act in the best interests of user security and
revoke the intermediate. Wrongdoing warranting revocation definitely
includes using the issuing CA to intercept communication where the
certificate holder does not control the domain.

We already received a formal report on the serial number issue. This issue
reminds me of past discussion
(https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr
opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which
did not warrant removal from the root store. We plan on filling a bug report
on the incident and working with DarkMatter to ensure their systems are
compliant with the BRs. This includes their replacing non-compliant
certificates in accordance with 4.9.1.1. Considering that the certificates
resulted from a misreading of the BRs rather than a malicious act and the
historical precedent in not removing CAs for entropy issues, I don't think
there is justification to revoke the CA. IWe, of course, expect DarkMatter
to update their systems and work with the Mozilla community in providing all
information necessary to resolve concerns about their operation.

Hopefully that answers questions you have.  Feel free to ask me anything.

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, February 25, 2019 9:53 AM
To: Nick Lamb ; dev-security-policy@lists.mozilla.org
Cc: Kurt Roeckx 
Subject: Re: DarkMatter Concerns

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue 
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate 
> CAs, between the cPanel intermediate (all day-to-day operations 
> presumably by Sectigo and 

RE: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

If DarkMatter is issuing from a CA that chains to a Quovadis root trusted by
Mozilla, the issuance is in scope of the Mozilla policy.  But that also
means the cert is publicly trusted. Thus, I read it as "all TLS certs issued
from the public ICA are publicly logged", which matches what Scott told me
in the past. 

You really can't log private certs as they don't chain to a root trusted by
any of the CT logs.

-Original Message-
From: dev-security-policy  On
Behalf Of Buschart, Rufus via dev-security-policy
Sent: Monday, February 25, 2019 1:08 PM
To: mozilla-dev-security-policy

Subject: AW: DarkMatter Concerns

> Von: dev-security-policy 
>  Im Auftrag von Matthew
Hardeman via dev-security-policy On Mon, Feb 25, 2019 at 12:15 PM Richard
Salz  wrote:
> 
> > You miss the point of my question.
> >
> > What types of certs would they issue that would NOT expect to be 
> > trusted by the public?
> I get the question in principle.  If it is a certificate not intended 
> for public trust, I suppose I wonder whether or not it's truly in scope
for policy / browser inclusion / etc discussions?

If the certificate is part of a hierarchy that chains up to a root under
Mozillas Root Program there should be no question about this - yes it is in
scope.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich,
HRB 6684; WEEE-Reg.-No. DE 23691322

 

___
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

RE: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

Hi all,

Sorry for the delayed response. Been traveling and haven't had a chance to
properly format my thoughts until now. 

As you all know, DigiCert recently acquired the Quovadis CA. As the operator
of the CA, DigiCert is responsible for the issuing CA controlled by
DarkMatter. DarkMatter controls the keys of the intermediate, have their own
CPS, and undergo their own annual audits. 

With one exception, DigiCert has a policy against signing externally
operated intermediate CAs capable of issuing TLS certificates. The exception
is for browser operators who want a cross-sign, which is not applicable in
this case. We've found that limiting external CAs provides a better
situation for users and the security community. As we've done in the past,
we feel there is a logical and legal way to address inherited contracts and
externally operating CAs so that we do not leave site operators and relying
parties using those sites in a lurch. We are committed to working with
DarkMatter on a plan that works for them and aligns to our policy.

As for DarkMatter, we have not received direct evidence of any intentional
mis-issuance or use of a certificate for a MiTM attack. As a policy, we do
not revoke certificates based purely on allegations of wrongdoing.  This is
true regardless of source, such as trademark disputes, government requests
for revocation, and similar matters. We do revoke certificates after
receiving a formal request for revocation from a trust store operator. I
think this policy is a logical approach as the policy avoids government
influence and public pressure over unpopular sites while acknowledging the
browser's control over their root store.

If we are presented with direct evidence of serious BR violations or
wrongdoing, we will certainly act in the best interests of user security and
revoke the intermediate. Wrongdoing warranting revocation definitely
includes using the issuing CA to intercept communication where the
certificate holder does not control the domain.

We already received a formal report on the serial number issue. This issue
reminds me of past discussion
(https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr
opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which
did not warrant removal from the root store. We plan on filling a bug report
on the incident and working with DarkMatter to ensure their systems are
compliant with the BRs. This includes their replacing non-compliant
certificates in accordance with 4.9.1.1. Considering that the certificates
resulted from a misreading of the BRs rather than a malicious act and the
historical precedent in not removing CAs for entropy issues, I don't think
there is justification to revoke the CA. IWe, of course, expect DarkMatter
to update their systems and work with the Mozilla community in providing all
information necessary to resolve concerns about their operation.

Hopefully that answers questions you have.  Feel free to ask me anything.

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, February 25, 2019 9:53 AM
To: Nick Lamb ; dev-security-policy@lists.mozilla.org
Cc: Kurt Roeckx 
Subject: Re: DarkMatter Concerns

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue 
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate 
> CAs, between the cPanel intermediate (all day-to-day operations 
> presumably by Sectigo and nobody from cPanel has the associated RSA 
> private keys)

Hi Nick.  I can confirm that all day-to-day operations for the cPanel
intermediates are performed by Sectigo, and nobody from cPanel has the
associated RSA private keys.

> and Let's Encrypt X3 (all day-to-day operations by Let's Encrypt / 
> ISRG and presumably nobody from IdenTrust has the associated RSA 
> private keys)


QuoVadis disclosed [1] that...

"The DarkMatter CAs were previously hosted and operated by QuoVadis, and
included in the QuoVadis WebTrust audits through 2017. In November 2017, the
CAs were transitioned to DarkMatter's own control following disclosure to
browser root programs."

I take that to mean that DarkMatter are in possession of the RSA private key
corresponding to https://crt.sh/?caid=22507.


[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: Audit Reminder Email Summary

[Kathleen Wilson via dev-security-policy]

Here's the summary of Mozilla's audit reminder emails that were sent 
last Tuesday. (I was on vacation last week).


Note that per previous discussion, the date logic for sending these 
emails has been updated, and is documented here:


https://wiki.mozilla.org/CA/Email_templates#Audit_Reminder_Email_Templates

- Audit Reminder is sent when previous Audit Period End date is 1 year 
plus 31 days to 93 days old.


- Overdue Notice is sent when previous Audit Period End date is 1 year 
plus 93 days to 150 days old.


- Danger of being removed warning is sent when previous Audit Period End 
date is older than 1 year plus 150 days.


Thanks,
Kathleen

 Forwarded Message 
Subject: Summary of February 2019 Audit Reminder Emails
Date: Tue, 19 Feb 2019 20:00:52 + (GMT)


Mozilla: Audit Reminder
CA Owner: Government of The Netherlands, PKIoverheid (Logius)
Root Certificates:
   Staat der Nederlanden EV Root CA
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden Root CA - G2
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8958479
Standard Audit Period End Date: 2017-12-31
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8958475
BR Audit Period End Date: 2017-12-31
EV Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8958477
EV Audit Period End Date: 2017-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Krajowa Izba Rozliczeniowa S.A. (KIR)
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221051

Standard Audit Period End Date: 2017-12-18
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221052

BR Audit Period End Date: 2017-12-18
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Buypass
Root Certificates:
   Buypass Class 2 Root CA
   Buypass Class 3 Root CA
Standard Audit: 
https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295

Standard Audit Period End Date: 2017-11-30
BR Audit: https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295
BR Audit Period End Date: 2017-11-30
EV Audit: https://bug1359516.bmoattachments.org/attachment.cgi?id=8956295
EV Audit Period End Date: 2017-11-30
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Hong Kong (SAR), Hongkong Post, Certizen
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221045

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221044

BR Audit Period End Date: 2017-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: QuoVadis
Root Certificates:
   QuoVadis Root CA 1 G3
   QuoVadis Root CA 2
   QuoVadis Root CA 2 G3
   QuoVadis Root CA 3
   QuoVadis Root CA 3 G3
   QuoVadis Root Certification Authority
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221092

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221093

BR Audit Period End Date: 2017-12-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221094

EV Audit Period End Date: 2017-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Taiwan-CA Inc. (TWCA)
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221109

Standard Audit Period End Date: 2017-12-31
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221112

BR Audit Period End Date: 2017-12-31
EV Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=22

EV Audit Period End Date: 2017-12-31
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT)
Root Certificates:
   FNMT-RCM - SHA256
Standard Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

Standard Audit Period End Date: 2018-01-12
BR Audit: 
https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2018041201_Audit_Attestation_s.pdf

BR Audit Period End Date: 2018-01-12
CA Comments: null



Mozilla: Audit Reminder
CA Owner: Amazon Trust Services
Root Certificates:
   Amazon Root CA 3
   Amazon Root CA 2
   Starfield Services Root Certificate Authority - G2
   Amazon Root CA 1
   Amazon Root CA 4
Standard Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221192

Standard Audit Period End Date: 2018-01-15
BR Audit: 
http://www.cpacanada.ca/GenericHandlers/AptifyAttachmentHandler.ashx?AttachmentID=221193

BR Audit Period End Date: 2018-01-15
EV Audit: 

AW: DarkMatter Concerns

[Buschart, Rufus via dev-security-policy]

> Von: dev-security-policy  Im 
> Auftrag von Matthew Hardeman via dev-security-policy
> On Mon, Feb 25, 2019 at 12:15 PM Richard Salz  wrote:
> 
> > You miss the point of my question.
> >
> > What types of certs would they issue that would NOT expect to be
> > trusted by the public?
> I get the question in principle.  If it is a certificate not intended for 
> public trust, I suppose I wonder whether or not it's truly in scope for
> policy / browser inclusion / etc discussions?

If the certificate is part of a hierarchy that chains up to a root under 
Mozillas Root Program there should be no question about this - yes it is in 
scope.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

 

___
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 Mon, Feb 25, 2019 at 12:15 PM Richard Salz  wrote:

> You miss the point of my question.
>
> What types of certs would they issue that would NOT expect to be trusted
> by the public?
>
>>
>>>
I get the question in principle.  If it is a certificate not intended for
public trust, I suppose I wonder whether or not it's truly in scope for
policy / browser inclusion / etc discussions?
___
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]

The answer to the question of what certificates they intend to CT log or
not may be interesting as a point of curiosity, but the in-product CT
logging requirements of certain internet browsers (Chrome, Safari) would
seem to ultimately force them to CT log the certificates that are intended
to be trusted by a broad set of internet browsers.

On Mon, Feb 25, 2019 at 12:01 PM rich.salz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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?
> ___
> 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

[rich.salz--- via dev-security-policy]

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?
___
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]

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate
> CAs, between the cPanel intermediate (all day-to-day operations
> presumably by Sectigo and nobody from cPanel has the associated RSA
> private keys)

Hi Nick.  I can confirm that all day-to-day operations for the cPanel 
intermediates are performed by Sectigo, and nobody from cPanel has the 
associated RSA private keys.

> and Let's Encrypt X3 (all day-to-day operations by Let's
> Encrypt / ISRG and presumably nobody from IdenTrust has the associated
> RSA private keys)


QuoVadis disclosed [1] that...

"The DarkMatter CAs were previously hosted and operated by QuoVadis, and 
included in the QuoVadis WebTrust audits through 2017. In November 2017, 
the CAs were transitioned to DarkMatter’s own control following 
disclosure to browser root programs."

I take that to mean that DarkMatter are in possession of the RSA private 
key corresponding to https://crt.sh/?caid=22507.


[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx

-- 
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

[Nick Lamb via dev-security-policy]

On Sat, 23 Feb 2019 10:16:27 +0100
Kurt Roeckx via dev-security-policy
 wrote: 
> I would also like to have a comment from the current root owner
> (digicert?) on what they plan to do with it.

Two other things would be interesting from Digicert on this topic

1. To what extent does DarkMatter have practical ability to issue
independently of Digicert?

https://crt.sh/?caid=22507

It would be nice to know where this is on the spectrum of intermediate
CAs, between the cPanel intermediate (all day-to-day operations
presumably by Sectigo and nobody from cPanel has the associated RSA
private keys) and Let's Encrypt X3 (all day-to-day operations by Let's
Encrypt / ISRG and presumably nobody from IdenTrust has the associated
RSA private keys)


2. Does Digicert agree that currently misissuances, even on seemingly
minor technical issues like threadbare random serial numbers are their
problem, since they are the root CA and ultimately responsible for this
intermediate ?


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

Re: DarkMatter Concerns

[Tim Shirley via dev-security-policy]

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.

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

Please fix Dark Matter and DigiCert

[bettertechnology2--- via dev-security-policy]

Mozilla seems to be more and more of a problem.

Not only is there issues with Certificates there is also built in problems in 
Linux distributions.

Considering how much new work is starting for Machine Learning, drone and 
vehicle controls, we need Mozilla to be just as reliable as Google and 
Microsoft.

There’s no excuse for sub par security. 

Please be part of the solution, not part of the problem. 

Seriously 

Thank You 

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

Re: DarkMatter Concerns

[Jakob Bohm via dev-security-policy]

On 25/02/2019 11:42, Scott Rea wrote:

G’day Paul,

I cannot speak for other CAs, I can only surmise what another CA that is as 
risk intolerant as we are might do. For us, we will collision test since there 
is some probability of a collision and the test is the only way to completely 
mitigate that risk.
There is a limitation in our current platform that sets the serialNumber 
bit-size globally, however we expect a future release will allow this to be 
adjusted per CA. Once that is available, we can use any of the good suggestions 
you have made below to adjust all our Public Trust offerings to move to larger 
entropy on serialNumber determination.

However, the following is the wording from Section 7.1 of the latest Baseline 
Requirements:
“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.”

Unless we are misreading this, it does not say that serialNumbers must have 
64-bit entropy as output from a CSPRNG, which appears to be the point you and 
others are making. If that was the intention, then perhaps the BRs should be 
updated accordingly?

We don’t necessarily love our current situation in respect to entropy in 
serialNumbers, we would love to be able to apply some of the solutions you have 
outlined, and we expect to be able to do that in the future. However we still 
assert that for now, our current implementation of EJBCA is still technically 
complaint with the BRs Section 7.1 as they are written. Once an update for 
migration to larger entropy serialNumbers is available for the platform, we 
will make the adjustment to remove any potential further isssues.

Regards,
  



I believe the commonly accepted interpretation of the BR requirement is
to ensure that for each new certificate generated, there are at least
2**64 possible serial numbers and no way for anyone involved to predict
or influence which one will be used.

This rule exists to prevent cryptographic attacks on the algorithms used
for signing the certificates (such as RSA+SHA256), and achieves this
protection because of the location of the serial number in the
certificate structure.

If all the serial numbers are strictly in the range 0x0001
to 0x7FFF then there is not enough protection of the signing
algorithm against these attacks.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
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 Paul,

I cannot speak for other CAs, I can only surmise what another CA that is as 
risk intolerant as we are might do. For us, we will collision test since there 
is some probability of a collision and the test is the only way to completely 
mitigate that risk.
There is a limitation in our current platform that sets the serialNumber 
bit-size globally, however we expect a future release will allow this to be 
adjusted per CA. Once that is available, we can use any of the good suggestions 
you have made below to adjust all our Public Trust offerings to move to larger 
entropy on serialNumber determination.

However, the following is the wording from Section 7.1 of the latest Baseline 
Requirements:
“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.”

Unless we are misreading this, it does not say that serialNumbers must have 
64-bit entropy as output from a CSPRNG, which appears to be the point you and 
others are making. If that was the intention, then perhaps the BRs should be 
updated accordingly?

We don’t necessarily love our current situation in respect to entropy in 
serialNumbers, we would love to be able to apply some of the solutions you have 
outlined, and we expect to be able to do that in the future. However we still 
assert that for now, our current implementation of EJBCA is still technically 
complaint with the BRs Section 7.1 as they are written. Once an update for 
migration to larger entropy serialNumbers is available for the platform, we 
will make the adjustment to remove any potential further isssues.

Regards,
 

-- 

Scott Rea

On 2/25/19, 1:32 PM, "dev-security-policy on behalf of Paul Kehrer via 
dev-security-policy"  wrote:

Hi Scott,

Comments inline.

On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

G’day Corey,

To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in
the serialNumber is to generate the required output and then test it to see
if it can be a valid serialNumber. If it is not a valid serialNumber, it is
discarded, and new value is generated. This process is repeated until the
first valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate
each serialNumber that gets used, and this is complaint with the BRS
Section 7.1.

This approach (assuming it is accurately described) discards exactly half
of all values, thus halving the address space. That means there are 63-bits
of entropy, so I do not agree that this process is compliant with the
baseline requirements. More generally, RFC 5280 allows up to 20 octets in
the serial number field so why are you choosing to issue on the lower bound?



I will also point out that if the returned value is a valid as a
serialNumber, it is further checked to see if that value has not been used
before, since there is obviously a minimal chance of collision in any truly
random process. In this case the serialNumber value will also be discarded
and the process repeated.

I don't believe all public CAs do collision detection because many have
chosen to implement serial generation such that collision is highly
improbable. For example, a CA may choose to generate a 160-bit value and
clamp the high bit to zero. This provides 159-bits of entropy, with a
collision probability of roughly 1 in 2 ** 79.5. Alternately, a CA might
choose to issue with 80-bits of entropy concatenated with a 64-bit
nanosecond time resolution timestamp. This provides 1 in 2 ** 40 collision
probability for any given nanosecond. As a final example, Let's Encrypt's
Boulder CA generates a 136-bit random value and prefixes it with an 8-bit
instance ID:

https://github.com/letsencrypt/boulder/blob/a9a0846ee92efa01ef6c6e107d2e69f4ddbea7c0/ca/ca.go#L511-L532

1 in 2 ** 79.5 is roughly as probable as a randomly generated number
successfully passing typical Miller-Rabin primality testing while in
reality being composite. This is not a risk we worry about when creating
new root keys.


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.



Regards,


-- 

Scott Rea
 

Scott Rea | Senior Vice President - Trust Services 
Tel: +971 2 

Re: DarkMatter Concerns

[Paul Kehrer via dev-security-policy]

Hi Scott,

Comments inline.

On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

G’day Corey,

To follow up on this thread, we have confirmed with the developers of the
platform that the approach used to include 64-bit output from a CSPRNG in
the serialNumber is to generate the required output and then test it to see
if it can be a valid serialNumber. If it is not a valid serialNumber, it is
discarded, and new value is generated. This process is repeated until the
first valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate
each serialNumber that gets used, and this is complaint with the BRS
Section 7.1.

This approach (assuming it is accurately described) discards exactly half
of all values, thus halving the address space. That means there are 63-bits
of entropy, so I do not agree that this process is compliant with the
baseline requirements. More generally, RFC 5280 allows up to 20 octets in
the serial number field so why are you choosing to issue on the lower bound?



I will also point out that if the returned value is a valid as a
serialNumber, it is further checked to see if that value has not been used
before, since there is obviously a minimal chance of collision in any truly
random process. In this case the serialNumber value will also be discarded
and the process repeated.

I don't believe all public CAs do collision detection because many have
chosen to implement serial generation such that collision is highly
improbable. For example, a CA may choose to generate a 160-bit value and
clamp the high bit to zero. This provides 159-bits of entropy, with a
collision probability of roughly 1 in 2 ** 79.5. Alternately, a CA might
choose to issue with 80-bits of entropy concatenated with a 64-bit
nanosecond time resolution timestamp. This provides 1 in 2 ** 40 collision
probability for any given nanosecond. As a final example, Let's Encrypt's
Boulder CA generates a 136-bit random value and prefixes it with an 8-bit
instance ID:
https://github.com/letsencrypt/boulder/blob/a9a0846ee92efa01ef6c6e107d2e69f4ddbea7c0/ca/ca.go#L511-L532

1 in 2 ** 79.5 is roughly as probable as a randomly generated number
successfully passing typical Miller-Rabin primality testing while in
reality being composite. This is not a risk we worry about when creating
new root keys.


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.



Regards,


-- 

Scott Rea
___
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 Corey,

To follow up on this thread, we have confirmed with the developers of the 
platform that the approach used to include 64-bit output from a CSPRNG in the 
serialNumber is to generate the required output and then test it to see if it 
can be a valid serialNumber. If it is not a valid serialNumber, it is 
discarded, and new value is generated. This process is repeated until the first 
valid serialNumber is produced.

This process ensures that 64 bits output from a CSPRNG is used to generate each 
serialNumber that gets used, and this is complaint with the BRS Section 7.1.

I will also point out that if the returned value is a valid as a serialNumber, 
it is further checked to see if that value has not been used before, since 
there is obviously a minimal chance of collision in any truly random process. 
In this case the serialNumber value will also be discarded and the process 
repeated.

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.

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.

On 2/25/19, 6:11 AM, "Scott Rea"  wrote:

G’day Corey,

I am not sure if the phrase “…outputting 64 random bits from the CSPRNG and 
then coercing the most significant bit to 0” is actually an accurate 
representation of what is happening under the covers – we have asked for 
clarification from the developers so we can all have an informed discussion (I 
know that DM is not the only CA using this platform). My anticipation is that 
what happens is that CSPRNG process is repeated until a positive INTEGER is 
returned. In which case a 64-bit output from a CSPRNG is contained in the 
serialNumber as is required. Please note, the requirement is not a 64-bit 
number, but that a 64-bit output from a CSPRNG process is contained in the 
serialNumber, and we believe this is exactly what is happening.


Regards,
 

-- 

Scott Rea

On 2/25/19, 5:48 AM, "dev-security-policy on behalf of Corey Bonnell via 
dev-security-policy"  wrote:

Hi Scott,
Thank you for the prompt response and the transparency in regard to the 
software stack used by your CA operations. The detailed response that you 
provided will hopefully make it easier to highlight the disconnect we have.

You are correct that ASN.1 INTEGERs are 2's-complement signed integers. 
Every DarkMatter-issued certificate that I've encountered (both those chained 
to Digicert roots as well as your roots as well as the DarkMatter root 
certificates themselves) has an INTEGER data size of exactly 8 octets (64 
bits). By outputting 64 random bits from the CSPRNG and then coercing the most 
significant bit to 0 (to make the INTEGER value positive, as you mentioned) 
means that the CA software is discarding one bit from the CSPRNG (since the 
most significant bit is being coerced to 0) and embedding only 63 bits of 
CSPRNG output in the certificate serial number. Section 7.1 of the Baseline 
Requirements requires at least 64 bits output from a CSPRNG, so I do not 
believe the serial number generation scheme that you have described is 
compliant.

Thanks,
Corey






 






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