Re: Discovering unlogged certificates in internet-wide scans

[Eric Mill via dev-security-policy]

Did you submit the ~25K unexpired unlogged certs to CT?

On Sat, Mar 31, 2018 at 6:14 PM, Tim Smith via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi MDSP,
>
> I went looking for corpuses of certificates that may not have been
> previously logged to CT and found some in the Rapid7 "More SSL" dataset,
> which captures certificates from their scans of non-HTTPS ports for
> TLS-speaking services.
>
> I wrote up some findings at
> http://blog.tim-smith.us/2018/03/moressl-spelunking/.
>
> A few highlights include:
> - of the ~10 million certificates in the corpus, about 20% had valid
> signatures and chained to roots included in the Mozilla trust store
> - about 50,000 of the 2 million trusted certificates had not previously
> been logged
> - about half of the novel certificates were unexpired
>
> There were interesting examples of unexpired, non-compliant, trusted
> certificates chaining to issuers including GoDaddy, NetLock, Logius, and
> Entrust. (I have not taken any action to inform issuers of these findings,
> other than this message and by publishing the certificates to CT logs.)
>
> I welcome any feedback or questions about the value of the approach and the
> findings.
>
> Thanks,
> Tim
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Tom Prince via dev-security-policy]

On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote:
> I fully understand the proposed solution about 2018 roots but as I previously 
> said some concerns arise, [...]


That is unfortunate for Camerfirma, but it is not Mozilla or this lists issue. 
While people have provided some suggestions on how you can create a root that 
*might* be acceptable, I don't think any of the participants care if Camerfirma 
has a root accepted; given the issues previously identified and the responses 
to those issues, I think a number of participants would be just as happy if 
Camerfirma doesn't get accepted.

> 
> [...] A complete revocation of any SSL certificate issued by 2016 root [...]

There are at least a couple of problems with this
1. Revocation, while a useful tool to have, there are a number of issues 
surrounding it, including distribution of those revocations. Given that the 
root isn't currently trusted it doesn't make sense for Mozilla to start 
trusting it but also need to ship a bunch of revocations for mis-issued 
certificates from it.
2. Given the issues that have already occured with this root, there is going to 
be questions of whether all the certificates that it has issued are properly 
recorded, so that they can now be revoked. That is, given the existing issues, 
how can Mozilla be confident that all the certificates will be revoked. This is 
not a question of willingness, but rather capability to identify and revoke all 
the certificates signed by this root.

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[ramirommunoz--- via dev-security-policy]

El domingo, 1 de abril de 2018, 16:29:08 (UTC+2), westm...@gmail.com  escribió:
> Hi, Ramiro.
> But how will the problems persecuting your CA disappear, even if the root is 
> sterile.
> 
> Andrew

Thank you Andrew for your comment.

We have already solve the problems located in this bug, and develop the 
technical controls that will avoid to be replicated in the future.

Our proposal is:

Revoke all certificates issued under this root. This is not strictly necessary 
since all live certificates under this root are correctly issued.
 
Provide a "point in time" BR audit to prove to the community that all control 
are placed to avoid new misissued certificates, and that this root fulfill BR 
requirement.

Finally starting to issue new certificates.

IOHO these actions can avoid to start a new root from the scratch. 

I do know if this answer your question. 

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[westmail24--- via dev-security-policy]

Hi, Ramiro.
But how will the problems persecuting your CA disappear, even if the root is 
sterile.

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

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[ramirommunoz--- via dev-security-policy]

El viernes, 30 de marzo de 2018, 17:06:35 (UTC+2), Wayne Thayer  escribió:
> On Wed, Mar 28, 2018 at 3:45 AM, ramirommunoz--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> >
> > On Tuesday, March 27, 2018 at 10:37:07 PM UTC+2, Wayne Thayer wrote:
> > > Hi Ramiro,
> > >
> > > On Fri, Mar 23, 2018 at 11:52 AM, ramirommunoz--- via
> > dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > Hi Ryan
> > > >
> > > > Thanks again for your remarks.
> > > > In the end I am going to learn something of PKI :-).
> > > > Surely I do not get a full understanding of you solution, but public
> > > > administration is requiring a EU qualified Web certificate this means
> > that
> > > > should be included in the EUTL. I do know other solution for a new
> > root but
> > > > a new conformity assessment.
> > > >
> > > > If the "2016" roots are included in the EUTL, then they can be used to
> > > sign ("cross-sign") a new "2018" root (or roots) that will then inherit
> > the
> > > trust from the "2016" root. From the perspective of the EUTL, the new
> > root
> > > would look like a new intermediate CA certificate.
> >
> > Wayne, the EUTL do not include ROOTS, only SubCA. It doesn't works in this
> > way. Our hypothetical new 2018 root should issue a SubCA for WEBSITE
> > certificates and this SubCA should be included in the EUTL, previously we
> > should pass a new conformity assessment and send it to our National
> > Supervisor body..and so on.
> >
> > In that case, the new "2018" root(s) could be used to cross-sign the older
> roots to provide a transition that allows your "2016" roots to be trusted
> in Mozilla products until the "2018" SubCAs are added to the EUTL.
> 
> > >
> > > Nevertheless, let me insist. In which aspects a new root 2018 improve our
> > > > trustworthiness instead of the current root 2016?
> > > >
> > > > This is the wrong question to ask. For all the reasons stated in
> > earlier
> > > messages, the Mozilla community appears to have concluded that the 2016
> > > roots are not trustworthy. If that is the case, then the proposal that
> > you
> > > create a new root answers the question that I think you should be asking:
> > > "How can Camerfirma regain the community's trust?" Submitting a new root
> > > that has been audited, has no history of misissuance, and complies in
> > every
> > > way with our policies has been proposed as one possible way to increase
> > > confidence in your CA. If you have been following this mailing list, you
> > > have seen that this same action has been recommended to other CAs that
> > are
> > > in this situation.
> > >
> >
> > Wayne, all issues stated are already resolved, Moreover actually 2016 root
> > is not affected by those problems. That's why I do not see the difference
> > between 2016 root and a new 2018 root.
> >
> > Documented misissuance from the 2016 roots:
> https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01
> 
> Moreover, all of the CPS issues that I identified apply to the 2016 roots,
> and many of the other issues - such as CAA failures - apply equally to
> these roots. So why do you believe that the '2016 root is not affected by
> those problems'?
> 
> Nevertheless We offer a "Point in time audit" over 2016 root in order to
> > provide to the community a clear assurance that all technical controls are
> > in place and fulfill the BR requirements. Previously, to start from a clean
> > point, We offer as well to revoke all WebSite certificates issued under
> > this root.
> >
> > We think that this proposal should provide a similar situation that we
> > would have if a new 2018 root were set up.
> >
> > Regards
> > Ramiro
> >
> >
Hi Wayne
Thank you again for your answer

I fully understand the proposed solution about 2018 roots but as I previously 
said some concerns arise, not only for timing issues, but also from unexpected 
behaviours in some environment (EUTL, Spanish Public Administration validation 
platforms...etc) that could have a significant impact in our certificate 
distribution, so if we can we would like to avoid this solution.

What about Camerfirma proposal:

1.- A complete revocation of any SSL certificate issued by 2016 root
2.- "Point in time" BR audit
3.- Start issuing certificates from a clean environment from 2016 root

This would be a quicker and good solution for us and we think this guarantee 
the community that everything is corrected and ok from this point on.

Best Regards
Ramiro

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