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 < > [email protected]> 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. > > 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. 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
