Re: FW: StartCom inclusion request: next steps

[Jakob Bohm via dev-security-policy]

On 14/09/2017 17:05, Inigo Barreira wrote:

All,

...


We should add the existing Certnomis cross-signs to OneCRL to revoke all the
existing certificates. As of 10th August (now a month ago) StartCom said they
have 5 outstanding SSL certs which are valid due to the Certnomis cross-
sign.


I´ve never said this. In fact, despite having that cross-signed which were 
provided to us in july we have never used and provided to any of our customers 
to build a trusted path. So none of those 5, or the new ones, go with the 
Certinomis path because none have it. But all those 5 certs are untrusted 
because we´re not in the Mozilla root, not the new one, and the old one was 
distrusted.
In fact, recently, I asked for permission to use the Certinomis cross-signed 
certificates and have no response. I don´t know if this is an administrative 
silence which may allow me to use it but until having a clear direction we 
haven´t used it.




I can't speak for Mozilla, but the obvious point is, that as soon as
the cross certificate from Certinomis was published in CT-logs or
elsewhere, any StartCom customer could (and still can) download it and
install it on their server, thus activating the Certinomis path for
their server.


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: CAA Certificate Problem Report

[Jakob Bohm via dev-security-policy]

On 14/09/2017 01:13, Matthew Hardeman wrote:

On Tuesday, September 12, 2017 at 5:36:56 AM UTC-5, Gervase Markham wrote:



As the drafter of the section :-), my intent was to make it so that if a
site owner were concerned about the possibility that their CAA record or
DNS could be spoofed, they could use DNSSEC to solve the problem. I
agree that there is an implicit assumption in this requirement, that it
is possible to efficiently determine the presence or absence of what we
might call "attempted DNSSEC" for a particular domain. (That's not the
same thing as "correct, valid, properly-signed, whatever DNSSEC.) If
that assumption is not true, we may have to reconsider.


The proper mechanism is, of course, proper DNSSEC validation of each step of 
each of the CAA queries.

The only "light" mechanism I can imagine is likely to shave only a little time 
off of common cases and is more likely to introduce bugs and errors for edge cases than 
it will help, but here goes:

I _think_ the only "light" DNSSEC validation shortcut that might pass muster 
would be:

1.  Chase validation to TLD from root zone.
2.  Query for DS record delegation for second-level-domain from the TLD 
servers, validating proper signature on the DS results or proper signature on 
the proof-of-non-existence of the DS records for the SLD.
3.  If the SLD has DS records at the registry and these DS results are signed 
by the registry, assume that the SLD and all downline subordinates of the SLD 
have DNSSEC configured and perform full DNSSEC validation on each CAA query.  
If the SLD has no DS records in the TLD registry and this has been _proven_ by 
a validly signed proof-of-nonexistence by the TLD registry servers, then DNSSEC 
for the SLD and subordinate zones is moot and could be ignored.

For the common case, I don't think that will shave off much time.  
Additionally, in terms of complexity, if you implement the above correctly, 
you've written the vast majority of the code necessary to finish it out the 
rest of the way.

Ultimately, a decision must be made as to whether or not the CA is responsible 
to ensure that the CAA records (or in the alternative that the non-existence of 
the CAA records) are fully DNSSEC validated wherever there is not a 
cryptographic proof that the zone doesn't support DNSSEC (Exempting for TLDs 
not supporting DNSSEC).

Matt Hardeman



Wouldn't the following also work:

1. Use a (non-broken) DNSSEC-validating recursive resolver/dnscache
  server running in the CA's own network.  Use more than one for
  redundancy.  This server will do all the DNSSEC checking and chasing.
  The network connection to this server must be secure.
2. If a DNS query response is NOERROR or NXDOMAIN and has the AD bit
  set, it is known to be validly signed.
3. If a DNS query response is NOERROR or NXDOMAIN, and does not have AD
  set, then it is a valid response from a zone that does not have a
  DNSSEC chain to the root zone.
4. If a DNS query response times out or is SERVFAIL, wait a bit then try
  again (a limited number of times).
5. If a DNS query response is ultimately anything else, something
  is wrong at the customer end (their DNS is broken), at the CA end (the
  DNS resolver/cache failed), or an attack is in progress.  Neither
  should result in issuance.

Note that the above is not specific to CAA, it should also work for any
A, , TXT or other records looked up during domain checks.

Note that a missing record (such as a missing CAA record) would result
in a valid response that is NOERROR or NXDOMAIN and which indicates that
no such record is there.

Real world experience may add a few other error codes indicating valid
absence of a record in an unsigned zone.


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: FW: StartCom inclusion request: next steps

[Nick Lamb via dev-security-policy]

On Thursday, 14 September 2017 16:00:35 UTC+1, Inigo Barreira  wrote:
> Well, finally this is a business and I don´t think none on this list is 
> working for free. At the end everyone has his/her salary, etc. But that was 
> not the main reason because getting included in the root programs takes time 
> but wanted to provide our customers which gave us support for what happened 
> with the distrust (which IMHO in the case of Startcom was very aggressive) a 
> solution generating a new fresh and clean system.

I can't speak for other people contributing to m.d.s.policy but of course I am 
not paid to do this. I have a job, but it isn't this. I have never asked my 
employer's permission to contribute here, judging it to be entirely outside 
their purview. My job does include running a (small, private) CA, but then it 
also includes maintaining a DBMS, a web crawler and all sorts of other stuff, 
I'm sure it would be possible to identify some connection to my job for almost 
any technical contribution I could make anywhere.

There is an proverb in English, I am not sure if you're familiar with it, "More 
haste, less speed". What this means is that in trying to perform a task as 
quickly as possible you may instead cause yourself such extra trouble that in 
the end the task takes even longer to complete. I am sure that even if you have 
not come across a phrase like this before you can see its applicability to the 
situation for StartCom.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom inclusion request: next steps

[Percy via dev-security-policy]

"Conclusion: StartCom's attempt to restart the CA was rushed."

"It was a very hard task in very few time but the people at 360 tried 
everything to get it done by that date, end of december 2016, and yes, we 
reached the date but with many failures"

May I ask why StartCom choose to rush everything in PHP from the ground up 
rather than using the more secure system already in place in the old StartCom?  
From my understanding, the distrust of StartCom is more related to the secret 
acquisition by  WoSign an Qihoo 360 rather than insecure infrastructure. So if 
the deadline is so imminent as you stated and pressure is so high from 
customers, can't you use the reasonably secure old code base rather than 
rushing everything from the ground up? Then you will have more time transition 
to another system if needed with sufficient time for secure processes?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Ryan Sleevi via dev-security-policy]

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
>
>
>
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> committed to meeting the Mozilla and Google plans in transitioning away
> from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the
> CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert.  We will post updates and plans to the
> community as things change and progress.
>
>
>
> I wanted to post to the Mozilla dev list to:
>
> 1.  Inform the public,
> 2.  Get community feedback about the transition and concerns, and
> 3.  Get an update from the browsers on what this means for the plan,
> noting that we fully commit to the stated deadlines. We're hoping that any
> changes
>
>
>
> Two things I can say we plan on doing (following closing) to address
> concerns are:
>
> a.  We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. We also plan on limiting the number of organizations on
> each issuing CA.  We hope this will help address the "too big to fail"
> issue
> seen with Symantec.  By segregating end entities into roots and sub CAs,
> the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem.  This plan is very much in flux, and we'd
> love to hear additional recommendations.
> b.  Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient.  We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.
>
>
>
> Thanks a ton for any thoughts you offer.
>
>
>
> Jeremy
>

eremy,

Thanks for sharing details about your rough plans. There’s a lot at play
here, particularly when trying to fully visualize DigiCert’s existing and
proposed hierarchy, so I’m wondering if it might be easier to explore what
the ‘ideal PKI’ may look like, and then try to work backwards to figure out
how this acquisition can help that.

At the core, we can imagine there is a root CA for each major long-term
cryptographic configuration - which, in today’s world, generally means
RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may
also accommodate additional curves Ed25519 and Ed448, such as via
https://tools.ietf.org/id/draft-ietf-curdle-pkix . In total, this means the
ideal PKI only needs four to six root certificates.

Within each root, you can build out the appropriate segmentation. For
performance reasons, it’s likely preferable to have a ‘wide’ PKI (many
sub-CAs off the root, each constrained in capability and used for a limited
amount of time) versus a ‘deep’ PKI (hierarchically reducing the
capabilities at each level in the trust graph- for example, “All TLS” ->
“All DV” -> “All first party DV” -> “All first party DV in Q12017”), even
if a deep PKI can provide better compartmentalization for some use cases.

It isn’t clear that compartmentalizing on root provides any obvious
benefits to users, especially as it’s the same infrastructure and audits,
but it does seem that it increases the management overhead (for root
stores), the configuration challenges (for site operators), not to mention
the management (and, occasionally, network & memory) challenges for users
to support all of those roots.

It would be ideal to see DigiCert streamline its PKI to better align with
that vision, and to understand what challenges might prevent that. For
example, is there a path to transition all new DigiCert issuance to a
single root? If it can’t be done for all certs, can it be done for TLS?
Understanding if there are challenges to that goal can provide invaluable
insight into how the Managed CA transition can look.

A significant reason for the Managed CA plan was to provide a temporary
bridge for those TLS servers who had made risky and fragile technical
decisions - such as pinning to a single CA or only supporting a single CA
on a device - while minimizing the risk to the broader TLS ecosystem. As
Symantec, like other organizations wishing to operate a trusted CA, would
be permitted to apply to have new roots (and a new infrastructure)
included, once it had met the minimum required security standards, the

FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

All,

Obviously this is not the message we would like to read and will try to explain 
and rebate as much as possible some of the comments posted here.

> 
> The Mozilla CA Certificates team has been considering what the appropriate
> next steps are for the inclusion request from the CA "StartCom".[0] As readers
> will know, this CA has previously been removed from trust[1], and so a re-
> application obviously involves particular scrutiny. In addition, several
> questions have been raised about the way in which the new StartCom PKI has
> been operated technically[2]. This is a proposal for the way forward, on which
> comments are invited.
> 
> Mozilla's considered view is as follows:
> 
> * It should have been obvious to StartCom that testing of their new systems
> needed to be done using a parallel testing hierarchy.

Those tests were done to check the CT behaviour, there was any other testing of 
the new systems, just for the CT. Those certs were under control all the time 
and were lived for some minutes because were revoked inmediately after checking 
the certs were logged correctly in the CTs. It´s not a mis-issuance by means of 
we didn´t know what happened, we had to investigate, etc. It was not a good 
practice and I can´t excuse for that, but it was not related to the regular 
issuance procedure as someone suggested. We provided a report in which 
indicated all that happened and what we did to not happen this again, updating 
the EJBCA roles permissions.

 
> That it was not obvious, is deeply concerning. It is also concerning that 
> someone can sit at a terminal
> and issue random certificates with variable values in lots of fields, in what 
> is
> to become a publicly-trusted hierarchy.

Well, it was possible at that time, but only the CA administrator could do it 
and under many requirements. It´s not like sitting at a terminal and start 
issuing certificates, there were and are security mechanisms to avoid "someone" 
could do that and I can list many. Probably most of the CA administrators of 
the rest of CAs  had this capacity (maybe not now) because the majority of the 
PKI software allows it and it´s needed when building a hierarchy. 
 
> It's not about numbers (e.g. "40 out of 5"), it's about the process.
> 

This number of 40 is about the total of "mis-issuances" discovered, not only 
related to these ones for the CT testing. And some other times, discussed in 
this list, the number matters. Even more, for those 40, most of them were 
"discovered" by us and acted accordingly as per the BRs. We revoked the 
majority of them within the 24 hours of being notified internally. When those 
were posted in the bugzilla, as said, most were revoked and started the 
investigation on what happened and what actions needed to be done. Some of 
these "mis-issuances" were due to some incongruencies between the BRs and the 
Mozilla policy, such as the use of different curves (allowed by the BRs but not 
for some browsers), or about pre-certificates in which is not clear if they 
fall under what requirement as a discussion started by Jeremy on the list. For 
example, is it necessary to revoke also the pre-certificates when a certificate 
is revoked? Are they need to be considered certificates and meet the BRs and/or 
Mozilla policy?
Or about the use of Unicode vs punnycode which is still under discussions, even 
a ballot failed in the CABF. So, those errors we made were also made by some 
others, and not being as an excuse, but it seems that it was not clear for the 
CAs.

We updated our procedure issuance to avoid these issues happening in mid July. 
What did we do?
- Restrict the use of eliptic curves only to those admitted by Mozilla
- Change the certificate profile for not having differences with the key 
encipherment and key agreement
- update the internal db for country codes
- update the sytems for changing all domain names to punnycode
- and recently develop a csr checking tool to avoid the issue with RSA 
parameters because EJBCA didn´t have it at that time (it comes now with the new 
release 6.9.0)


> As JC Jones wrote:
> 
> "This is a professional PKI operation, being overseen by industry veterans. If
> something as concrete as the issuance process had such a glaring quality
> assurance methodology failure, why should anyone believe that something
> much harder -- subscriber validation -- is going to be done correctly?"

Well, this is an opinion. And I fully respect but none is free of failures and 
let´s encrypt (and many others) is also having them as we´re seeing recently 
with weak keys, etc. and I´m none to say they are not professional, or not 
having a quality assurance methodology, ... or for not believing they are not 
acting correctly. For sure they are, but same as us. I can´t critize anyone and 
not because we´re in a weak position at Startcom in which everyone is looking 
deeply what we do, scrutinizing deeply.
For all these failures we acted quickly because our internal 

Re: Violations of Baseline Requirements 4.9.10

[mihkeltammsalu--- via dev-security-policy]

> AS Sertifitseerimiskeskuse (SK)
> 
> CCADB does not list an email address. Not CC'd.
> 
> DN: C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA,
> emailAddress=p...@sk.ee
> Example cert:
> https://crt.sh/?q=74d992d3910bcf7e34b8b5cd28f91eaeb4f41f3da6394d78b8c43672d43f4f0f
> OCSP URI: http://ocsp.sk.ee/CA

Hello,

Thank you for your attention to the problem. SK ID Solutions is aware of the 
OCSP issue and we are already making detailed action plan for resolving the bug 
reported #1398233. If needed planning is made we will provide also the incident 
report.

Mihkel Tammsalu
SK ID Solutions AS
Service Manger
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom inclusion request: next steps

[Jonathan Rudenberg via dev-security-policy]

> On Sep 14, 2017, at 04:49, Gervase Markham via dev-security-policy 
>  wrote:
> 
> We should add the existing Certnomis cross-signs to OneCRL to revoke
> all the existing certificates. As of 10th August (now a month ago)
> StartCom said they have 5 outstanding SSL certs which are valid due
> to the Certnomis cross-sign. Revoking them all by adding intermediates
> to OneCRL would therefore lead to non-negligible disruption. But these
> were issued by an org whose most recent audits are qualified, which is
> under sanction, and about whose issuance practices and process safety
> there is a reasonable amount of doubt. We may allow a grace period for
> customers to replace them with certs from a trusted provider.

I’m not yet convinced a grace period is necessary. StartCom does not list 
Firefox as a compatible browser on their website (they have the logos for 
Internet Explorer, Microsoft Edge, Android, and Windows).

Additionally, there are multiple steps in the StartCom issuance flow that 
contain the following in red text:

> Notice: 
> 1. Mozilla and Google decided to distrust all StartCom root certificates as 
> of 21st of October, 2016, meaning that since January all the SSL certificates 
> issued from that date will no longer be trusted in Firefox and Chrome newest 
> releases. 
> Besides, Google has gone further and as explained here: 
> https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html 
> will not trust even those SSL certificates issued before that date until the 
> final disruption. 
> Apple's decision announced on Nov 30th, 2016 was to distrust all StartCom 
> root certificates as of 1st of December, meaning that SSL cert issued after 
> December 1st, 2016 will no longer be trusted in Apple’s systems. 
> 2. Any subscribers that paid the validation fee after Oct. 21st, 2016 can get 
> full refund by request. 
> 3. Currently StartCom is able to provide an interim solution for organization 
> users in case of requested. 
> Meanwhile StartCom is updating all systems and is following all requirements 
> requested by Mozilla to regain the trust in these browsers and re-apply after 
> the 6 months time penalty.

Given this explicit notification, I do not believe that subscribers would ever 
have had the expectation that their certificates would work with Firefox.

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