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