Re: ComSign Root Renewal Request
Dear Ryan You accuse our root status by saying:"We know that key has been run on deficient infrastructure, with deficient software, and done deficient things..." As a matter of a fact the ROOT resides on a FIPS140-2 L3 HSM and kept all it life time in an offline status (in a robust SAFE) and was participated in 3 key ceremonies. So why do you say that the infrastructure is deficient? You can question the certificate issued to this key - but why do you question the key itself? This is a very severe accusation. the "deficient things" is creating 2 subca's that wasn't comply with ONE condition of the BR (critical/ not critical of a certain field, which may declared AFTER we created these SUB's). So the Comsign ROOT KEY IS INTACT even if is signed subca keys which its certificates are not 100% according to BR. Can you agree? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
On Wed, Feb 14, 2018 at 10:47 AM, Tim Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote: > > In this particular case, my conclusion is that the existing Mozilla > > process is working. We have documented a number of issues that when > > considered in aggregate warrant an investigation. > > Hi Wayne, > > Forgive me if I'm overinterpreting your comment, but: does this mean that > an investigation is ongoing, or that Mozilla anticipates opening an > investigation? If there is or will be an investigation, do you have a > general sense of when to expect a result, and what that might look like? > > My comment means that I have acknowledged the issue and am looking into it, but haven't yet committed Mozilla to a specific course of action or timing. > Thanks, > Tim > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote: > In this particular case, my conclusion is that the existing Mozilla > process is working. We have documented a number of issues that when > considered in aggregate warrant an investigation. Hi Wayne, Forgive me if I'm overinterpreting your comment, but: does this mean that an investigation is ongoing, or that Mozilla anticipates opening an investigation? If there is or will be an investigation, do you have a general sense of when to expect a result, and what that might look like? Thanks, Tim ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
It seems to me that some CA's hold unanswered Mozilla's questions because they know that it will not cause any serious consequences. I mean removing a root certificates from Mozilla Root Store. However, this point of view here seems to have already been voiced. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
On Wed, Feb 14, 2018 at 10:29 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > We take your recommendation and we consider generating a brand new root > with a new key pair that will run only on the new CA software – whilst > providing all the audits and needed information as requested. > We need to know for certain before we initiate such a process that doing > so would be accepted by you and Ryan, and that we could continue from this > point, rather than starting over again at the beginning of the process. The Mozilla process does not guarantee trust as a pre-condition to taking actions. Merely, in rejecting an application, it can give the reasons why that application is rejected. Future submissions should therefore be mindful to avoid repeating the same mistakes. That does not prevent new mistakes from being made, thus new submissions should be mindful of the Baseline Requirement, the Mozilla CA Policy, and the set of community expectations and considerations that will be taken into account when evaluating whether or not to trust any new certificates. I do not believe it wise to accept this inclusion request, thus any new inclusion request should avoid these issues as part of the design and consideration - which would include ensuring that the infrastructure fully complies with the Baseline Requirements and equivalent system controls. You can always engage with an auditor or consultant to help design your system in a way to ensure compliance, both prior to generating your keys and certificate, and to ensure its continued compliance and responsiveness to industry and policy changes over time. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Public trust of VISA's CA
On Tue, Feb 13, 2018 at 11:26 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy ( > dev-security-policy@lists.mozilla.org) wrote: > > > The most recent BR audit report for the Visa eCommerce Root contains 3 > qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf > > Does Mozilla have any guidelines or official position on what constitutes > sufficient audit issues to result in sanctions? As Gerv described in the other thread [1], Mozilla's current approach is to document each issue and view them in aggregate, rather than defining a set of penalties that apply in given situations. Mozilla has certainly required actions from CAs as a condition to remaining in the program, but those "sanctions" have been defined in the context of specific situations. While I also find the idea of defining more generic penalties appealing on the surface, I'm not convinced that it would lead to better outcomes for our users. Frankly I'm stunned that > any CA in the Mozilla root program can apparently ignore the baseline > requirements for approximately 4 years after their effective date, get an > initial BR audit with multiple qualifications, and see no penalty from this > behavior. Their initial BR PITRA was in 2016. It lists 7 qualifications [2] And this is disregarding several other BR violations found in the > wild by independent researchers. I realize I'm banging the same drum as in > my other thread, but without consistent enforcement of escalating penalties > I don't believe we're teaching CAs anything other than that Mozilla will > ultimately forgive almost any transgression. Unless you catch them on a bad > day, in which case you might get distrusted entirely. > > In this particular case, my conclusion is that the existing Mozilla process is working. We have documented a number of issues that when considered in aggregate warrant an investigation. - Wayne [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/d-m48lVtYoQ/HvlXcfwWAQAJ [2] https://bug1301210.bmoattachments.org/attachment.cgi?id=8795503 -Paul (reaperhulk) > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
On Wed, Feb 14, 2018 at 10:27 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear Ryan > > We need to refer to the points you have raised regarding the ROOT KEY – we > must stress that the ROOT KEY and the ROOT CA are two different and > separate entities. > Whilst the ROOT CA does have some history the ROOT KEY was never (and > shouldn’t be) in question. > I do not believe there is sufficient public evidence to make this conclusion. > > “I hope you can understand that trust is not just based on the state of the > world 'today', but based on everything that key has ever done and every > bit of infrastructure that key has run on.” > You are now moving to discuss the root key. We have started a year > ago speaking of the CPS, than on the certificate, and now the ROOT KEY > itself. > Allow me to declare that the ROOT KEY is intact. It is kept on an > FIPS140-2 Level 3 HSM from its creation and always in an offline state as > should be. > You cannot put the key itself in any question. > You have, by virtue of the failures demonstrated. > “We know that key has been run on deficient infrastructure, with deficient > software, and done deficient things.” > >>> deficient infrastructure? The HSM is the ONLY infrastructure of the > ROOT KEY. The CA has nothing to do with the key itself. The KEY was NOT > running on deficient infrastructure and\or software! > > “The continued public examination has continued to find and discover new > issues since 2016. > While remedying these issues is a crucial minimum step towards trust, it > only gets you to a point where the current infrastructure might be suitable > to be trusted going forward. > Ensuring the creation of a new root, with new keys, which has never > certified any of the deficient infrastructure, is the only way the public > has to ensure they are not introducing additional risk to their users. “ > >>>We strongly disagree with that statement that a new KEY should be > generated – there’s never was any problem with the KEY therefore generating > a new one would not affect the integrity of the root as a whole. > We think the discussion should remain on the ROOT CA which had its > problems as discussed, and leave the KEY out of the discussion. > However, in order to come clean and regain your trust we would agree to > start a brand new root with a new key pair running on the new CA software > (and BR compliant of course) but before we do so, we would like to know for > certain that this process will be satisfactory and accepted by you. Public trust is based on the combination of the key and the name, not the certificate itself. The semantic quibbles aside, there should be no question that requiring a new "root certificate" is unquestionably the same as requiring a new subject name, with new key, to be generated. So regardless of your position about the existing key, I hope it's clear that a new key and new certificate should be generated. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Dear Wayne We do understand the issues raised and instead of addressing each one separately we would give a shorter answer: We do agree that mistakes were made with this rootCA and we understand your hesitation. We also believe that our current CPS state is well and that we made a lot of progress and we are in a good position today with the CPS which is according to the BR. We take your recommendation and we consider generating a brand new root with a new key pair that will run only on the new CA software – whilst providing all the audits and needed information as requested. We need to know for certain before we initiate such a process that doing so would be accepted by you and Ryan, and that we could continue from this point, rather than starting over again at the beginning of the process. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Dear Ryan We need to refer to the points you have raised regarding the ROOT KEY – we must stress that the ROOT KEY and the ROOT CA are two different and separate entities. Whilst the ROOT CA does have some history the ROOT KEY was never (and shouldn’t be) in question. “I hope you can understand that trust is not just based on the state of the world 'today', but based on everything that key has ever done and every bit of infrastructure that key has run on.” You are now moving to discuss the root key. We have started a year ago speaking of the CPS, than on the certificate, and now the ROOT KEY itself. Allow me to declare that the ROOT KEY is intact. It is kept on an FIPS140-2 Level 3 HSM from its creation and always in an offline state as should be. You cannot put the key itself in any question. “We know that key has been run on deficient infrastructure, with deficient software, and done deficient things.” >>> deficient infrastructure? The HSM is the ONLY infrastructure of the ROOT >>> KEY. The CA has nothing to do with the key itself. The KEY was NOT running >>> on deficient infrastructure and\or software! “The continued public examination has continued to find and discover new issues since 2016. While remedying these issues is a crucial minimum step towards trust, it only gets you to a point where the current infrastructure might be suitable to be trusted going forward. Ensuring the creation of a new root, with new keys, which has never certified any of the deficient infrastructure, is the only way the public has to ensure they are not introducing additional risk to their users. “ >>>We strongly disagree with that statement that a new KEY should be generated >>>– there’s never was any problem with the KEY therefore generating a new one >>>would not affect the integrity of the root as a whole. We think the discussion should remain on the ROOT CA which had its problems as discussed, and leave the KEY out of the discussion. However, in order to come clean and regain your trust we would agree to start a brand new root with a new key pair running on the new CA software (and BR compliant of course) but before we do so, we would like to know for certain that this process will be satisfactory and accepted by you. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
