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