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&opt=cablint,zlint,x509lint&minNotBefore=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
>
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
