Re: TunRootCA2 root inclusion request
I think this discussion has made it clear that the request for inclusion of the TunRootCA2 root should be denied. CAs inherently must be trusted, and trust must be earned. A CA can't simply fix one problem after another as we find them during the inclusion process and expect to be rewarded for their reactive efforts, nor can they ignore program requirements until the time comes to get their inclusion request approved. Recurrences of the same issue that the CA claimed to have fixed are especially damaging. As Ryan mentioned, section 7.1 of the Root Store Policy states that "We will determine which CA certificates are included in Mozilla's root program based on the benefits and risks of such inclusion to typical users of our products." While I believe the decision to deny this request is fully supported by that policy statement, I would be interested to know if anyone thinks there are ways we could make our expectations clearer in this regard. Regarding next steps, the Tunisian Government is welcome to submit a new root (using a newly generated key pair) for inclusion. The current bug may be reopened and used for the new request, but it will still need to go through the entire process. The only real "shortcut" in the inclusion process - as has been demonstrated by a few CAs recently who completed the process in 9-18 months) - is to have all the requirements fully met before the request is reviewed. Tests that are performed during the information verification process are documented [1], and every previous inclusion request is publicly accessible in Bugzilla and archives of this list, so this really shouldn't be as difficult as it seems to be. I agree with the comments Hans made on the desire to rapidly move through the process with the new request. Establishing confidence in a CA takes time, and attempts to move too quickly to regain trust can be extremely counterproductive (e.g. StartCom). Regarding the choice of auditor, Mozilla has not disqualified LSTI and so will not require a different auditor to be selected if/when a new root is submitted. However, given the concerns that have been raised with the current audits, choosing a different auditor may help to gain the confidence of the community in the new root and in the Tunisian Government CA. - Wayne [1] https://wiki.mozilla.org/CA:TestErrors On Thu, Mar 15, 2018 at 5:44 AM, okaphone.elektronika--- via dev-security-policy wrote: > On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com wrote: > > Dear Wayne, > > Based on the long discussion regarding our request, I would appreciate > having your opinion on the following: > > Move to a new root based on EJBCA (Enterprise License) and conduct a new > audit with a new auditor as required by Mozilla and the BR. > > We are ready and we do commit to do these steps in 6 months. As we hope > that you would accept to resume the inclusion process from this point. > > We are looking forward to hearing from you. > > > > Syrine. > > Do consider that it only makes sense to start with a new root (and do the > required audits etc.) when you are sure that all problems have been fixed, > in such a way that they (and others like them) will not happen again. > > Because if that isn't the case, the new root will soon be as useless as > trust-anchor as the old one. The fastest way forward is probably to not try > to do it quickly. > > CU Hans > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com wrote: > Dear Wayne, > Based on the long discussion regarding our request, I would appreciate having > your opinion on the following: > Move to a new root based on EJBCA (Enterprise License) and conduct a new > audit with a new auditor as required by Mozilla and the BR. > We are ready and we do commit to do these steps in 6 months. As we hope that > you would accept to resume the inclusion process from this point. > We are looking forward to hearing from you. > > Syrine. Do consider that it only makes sense to start with a new root (and do the required audits etc.) when you are sure that all problems have been fixed, in such a way that they (and others like them) will not happen again. Because if that isn't the case, the new root will soon be as useless as trust-anchor as the old one. The fastest way forward is probably to not try to do it quickly. CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Dear Wayne, Based on the long discussion regarding our request, I would appreciate having your opinion on the following: Move to a new root based on EJBCA (Enterprise License) and conduct a new audit with a new auditor as required by Mozilla and the BR. We are ready and we do commit to do these steps in 6 months. As we hope that you would accept to resume the inclusion process from this point. We are looking forward to hearing from you. Syrine. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Mon, Mar 12, 2018 at 10:53 PM, taher.mestiri--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I asked about fast tracks because it's taking long time to get things > processed related to the fact that all this is running by a community and I > think it can be great to brainstorm ways to handle maybe work overloads > even through paid assessments for example. > I think very few members of this community would see the time it takes to get a publicly trusted CA included as a problem. Indeed, it's actually rather quite the opposite - the time to get a CA included is likely not long enough, the time to get a CA removed is likely not fast enough, and the time for certificates to expire is not short enough. > I hope that you guys can give us a list of major corrections or > verifications to do within a certain limited time to give us the > opportunity to get our CA approved without restarting the whole process. > I hope this is not considered as special treatment as maybe I don't know > what kind of support you provide in such cases. > I shared a number of recommendations, based on the specific incidents highlighted, and the risks they posed. Restarting the whole process is something that has been requested of other CAs with similar deficiencies, because in a large part, this whole ecosystem is based on trust. For a CA to request inclusion, but not demonstrate sufficient technical understanding on how to manage that trust, is reasonable grounds to not trust them. Trust is not automatically granted and then slowly removed - rather, it's slowly earned, based on the quality of character and continued display of trustworthiness. In the case of this inclusion request, both the practices and the policies demonstrated significant gaps from what would be expected. An alternative answer might be to deny inclusion for 2 or more years, since that is often how long it can take to build an organization with both the technical expertise and the implementation to support it, as even the 'best' CAs can attest. However, I tried to offer a more targeted set of suggestions, based on the specific deficiencies that caused trust to be undermined here. While these are only my suggestions, it highlights the problematic patterns on display. In the end, I'm not sure why the Tunisian Government feels it should run a publicly trusted CA, so I don't know if there are other alternatives to suggest that might offer a more expedient, more secure, more reliable basis for trust. If that was to be shared, perhaps there are other solutions that may work. In the absence of that, the failures at the basic and core competencies of being a publicly trusted CA should be concerning. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: TunRootCA2 root inclusion request
My reaction was primarily based on the following suggestion: "Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive." The answer is, and must be, no. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > taher.mestiri--- via dev-security-policy > Sent: Monday, March 12, 2018 10:54 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TunRootCA2 root inclusion request > > Dear Tim, > > Not sure your penguin-related example would make the picture sharper or > ideas clearer. > > I asked about fast tracks because it's taking long time to get things processed > related to the fact that all this is running by a community and I think it can be > great to brainstorm ways to handle maybe work overloads even through paid > assessments for example. > > I don't think it's worth to answer either your comments about special > treatment, as no one has asked for it apart of speeding the process which is not > special treatment but respect for users and community, or about how special > we feel we are, etc. > > I am not a member of the government, I consider myself member of an open > global IT community, including but not limited to mozilla, that shares same > values of respect and mutual help. I find your answer a bit aggressive but, > anyway, maybe I was wrong about something that made you answer the way > you did... That was not my intention. > > I hope that you guys can give us a list of major corrections or verifications to do > within a certain limited time to give us the opportunity to get our CA approved > without restarting the whole process. > I hope this is not considered as special treatment as maybe I don't know what > kind of support you provide in such cases. > > At the end, I would reiterate that I shared personal opinions and I am not > member of the government as this is a public open discussion and I don't want > that my opinion impacts negaively the decision taking. > > Best, > > Taher. > > > > On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek wrote: > > Nobody is blocking any country from advancing. There are no Mozilla > > rules that prevent any country from having the best CA on the planet. > > If a bunch of penguins at McMurdo station run an awesome CA, I'll ask > > some hard questions about how they meet the OCSP requirements with > > their limited bandwidth, but if they have good answers, I'm fine with > > internet security now being penguins all the way down. > > > > If you want your certificates to be accepted everywhere on the planet, > > you need to follow the same rules as everyone else on the planet. No > > fast tracks or special rules for anyone, no matter how special they > > feel they are. > > > > The same rules for everyone is the only sane route forward. > > Governments often believe they deserve special treatment, and they may > > have the ability to force that to be true within their own country, > > but that doesn't make it a good idea for Mozilla. > > > > -Tim > > > > > -Original Message- > > > From: dev-security-policy [mailto:dev-security-policy- > > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > > taher.mestiri--- via dev-security-policy > > > Sent: Monday, March 12, 2018 7:31 PM > > > To: mozilla-dev-security-pol...@lists.mozilla.org > > > Subject: Re: TunRootCA2 root inclusion request > > > > > > Dear All, > > > > > > Thank you for your detailed description of your concerns with the > > > Tunisian > > CA. > > > > > > I have been one of those guys that developped IT communities for > > > more than > > 7 > > > years in Tunisia, starting by Tunandroid (Tunisian Android > > > Community), > > Google > > > Developers Groups, organized the best Software Freedom Day in 2012, > > > supported local Mozilla Community 2013-2014, GDG Country Champion in > > > Tunisia 2012-2014 and represented the IT community in law projects > > > to help developing the local ecosystem since 2013 and still. > > > > > > The reason why I am telling you this is to assure you that I > > > perfectly > > understand > > > what a community is about: helping each others, making things better > > > and sharing knowledge. Things have always been inclus
Re: TunRootCA2 root inclusion request
Dear Tim, Not sure your penguin-related example would make the picture sharper or ideas clearer. I asked about fast tracks because it's taking long time to get things processed related to the fact that all this is running by a community and I think it can be great to brainstorm ways to handle maybe work overloads even through paid assessments for example. I don't think it's worth to answer either your comments about special treatment, as no one has asked for it apart of speeding the process which is not special treatment but respect for users and community, or about how special we feel we are, etc. I am not a member of the government, I consider myself member of an open global IT community, including but not limited to mozilla, that shares same values of respect and mutual help. I find your answer a bit aggressive but, anyway, maybe I was wrong about something that made you answer the way you did... That was not my intention. I hope that you guys can give us a list of major corrections or verifications to do within a certain limited time to give us the opportunity to get our CA approved without restarting the whole process. I hope this is not considered as special treatment as maybe I don't know what kind of support you provide in such cases. At the end, I would reiterate that I shared personal opinions and I am not member of the government as this is a public open discussion and I don't want that my opinion impacts negaively the decision taking. Best, Taher. On Tuesday, 13 March 2018 03:06:40 UTC+1, Tim Hollebeek wrote: > Nobody is blocking any country from advancing. There are no Mozilla rules > that prevent any country from having the best CA on the planet. If a bunch > of penguins at McMurdo station run an awesome CA, I'll ask some hard > questions about how they meet the OCSP requirements with their limited > bandwidth, but if they have good answers, I'm fine with internet security > now being penguins all the way down. > > If you want your certificates to be accepted everywhere on the planet, you > need to follow the same rules as everyone else on the planet. No fast > tracks > or special rules for anyone, no matter how special they feel they are. > > The same rules for everyone is the only sane route forward. Governments > often believe they deserve special treatment, and they may have the ability > to force that to be true within their own country, but that doesn't make it > a good idea for Mozilla. > > -Tim > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > taher.mestiri--- via dev-security-policy > > Sent: Monday, March 12, 2018 7:31 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: TunRootCA2 root inclusion request > > > > Dear All, > > > > Thank you for your detailed description of your concerns with the Tunisian > CA. > > > > I have been one of those guys that developped IT communities for more than > 7 > > years in Tunisia, starting by Tunandroid (Tunisian Android Community), > Google > > Developers Groups, organized the best Software Freedom Day in 2012, > > supported local Mozilla Community 2013-2014, GDG Country Champion in > > Tunisia 2012-2014 and represented the IT community in law projects to help > > developing the local ecosystem since 2013 and still. > > > > The reason why I am telling you this is to assure you that I perfectly > understand > > what a community is about: helping each others, making things better and > > sharing knowledge. Things have always been inclusive. > > > > The Tunisian national digital certification agency has been under pressure > for > > more then 3 years to have its CA certificates recognized by Mozilla and > they did > > all which is possible to do to have the best security standards when they > got > > audited and criticized and they have alwyas been very reactive. > > > > I would highlight that we are speaking here about a national CA which is > > completely different from any other type of agencies. We are speaking > about > > blocking a whole country from advancing. > > > > It's already unacceptable to have such long process for country CA, if we > have > > to fail and restart we have to fail quickly because time is very valuable. > We > > can't afford restarting the process if the Tunisian CA gets rejected but > instead I > > think anything can be corrected and updated this is how I.T. works. > > > > Generally speaking I would insist on the fact that for country CAs, some > kind of > >
RE: TunRootCA2 root inclusion request
Nobody is blocking any country from advancing. There are no Mozilla rules that prevent any country from having the best CA on the planet. If a bunch of penguins at McMurdo station run an awesome CA, I'll ask some hard questions about how they meet the OCSP requirements with their limited bandwidth, but if they have good answers, I'm fine with internet security now being penguins all the way down. If you want your certificates to be accepted everywhere on the planet, you need to follow the same rules as everyone else on the planet. No fast tracks or special rules for anyone, no matter how special they feel they are. The same rules for everyone is the only sane route forward. Governments often believe they deserve special treatment, and they may have the ability to force that to be true within their own country, but that doesn't make it a good idea for Mozilla. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > taher.mestiri--- via dev-security-policy > Sent: Monday, March 12, 2018 7:31 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: TunRootCA2 root inclusion request > > Dear All, > > Thank you for your detailed description of your concerns with the Tunisian CA. > > I have been one of those guys that developped IT communities for more than 7 > years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google > Developers Groups, organized the best Software Freedom Day in 2012, > supported local Mozilla Community 2013-2014, GDG Country Champion in > Tunisia 2012-2014 and represented the IT community in law projects to help > developing the local ecosystem since 2013 and still. > > The reason why I am telling you this is to assure you that I perfectly understand > what a community is about: helping each others, making things better and > sharing knowledge. Things have always been inclusive. > > The Tunisian national digital certification agency has been under pressure for > more then 3 years to have its CA certificates recognized by Mozilla and they did > all which is possible to do to have the best security standards when they got > audited and criticized and they have alwyas been very reactive. > > I would highlight that we are speaking here about a national CA which is > completely different from any other type of agencies. We are speaking about > blocking a whole country from advancing. > > It's already unacceptable to have such long process for country CA, if we have > to fail and restart we have to fail quickly because time is very valuable. We > can't afford restarting the process if the Tunisian CA gets rejected but instead I > think anything can be corrected and updated this is how I.T. works. > > Generally speaking I would insist on the fact that for country CAs, some kind of > fast tracks should be established because the impact of time losing at country > level is highly expensive. > > I have no doubt about your support and hope you can help my country move > forward and I am sure that the team in our national digital certification agency > will do its best to assure you about how seriously we are working to make > users globally trusting our CA protected. > > Best regards, > > Taher Mestiri > > > > On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi wrote: > > These responses demonstrate why the request is troubling. They attempt > > to paint it as "other people do it" > > > > The risk of removing an included CA must balance the ecosystem > > disruption to those non-erroneous certs, while the risk to ecosystem > > inclusion needs to balance both the aggregate harm to the ecosystem > > (through lowered > > standards) and the risk to the ecosystem of rejecting the request (of > > which, until inclusion is accepted, is low) > > > > The pattern of issues - particularly for a new CA - is equally problematic. > > A CA, especially in light of the public discussions, should not be > > having these issues in 2018, and yet, here we are. > > > > We are in agreement on the objective facts - namely, that there is a > > prolonged pattern of issues - and the criteria - namely, that CAs > > should adhere to the policy in requesting inclusion. A strict > > adherence to those objectives would be to fully deny the request. It > > sounds like where we disagree, then, is not in the objective facts and > > criteria, but rather, where the evaluation of that leaves relative to risk. > > > > The position I am advocating is that, even if these individual matters > > might be seen as less risky, especially, as has been mentione
Re: TunRootCA2 root inclusion request
Dear All, Thank you for your detailed description of your concerns with the Tunisian CA. I have been one of those guys that developped IT communities for more than 7 years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google Developers Groups, organized the best Software Freedom Day in 2012, supported local Mozilla Community 2013-2014, GDG Country Champion in Tunisia 2012-2014 and represented the IT community in law projects to help developing the local ecosystem since 2013 and still. The reason why I am telling you this is to assure you that I perfectly understand what a community is about: helping each others, making things better and sharing knowledge. Things have always been inclusive. The Tunisian national digital certification agency has been under pressure for more then 3 years to have its CA certificates recognized by Mozilla and they did all which is possible to do to have the best security standards when they got audited and criticized and they have alwyas been very reactive. I would highlight that we are speaking here about a national CA which is completely different from any other type of agencies. We are speaking about blocking a whole country from advancing. It's already unacceptable to have such long process for country CA, if we have to fail and restart we have to fail quickly because time is very valuable. We can't afford restarting the process if the Tunisian CA gets rejected but instead I think anything can be corrected and updated this is how I.T. works. Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive. I have no doubt about your support and hope you can help my country move forward and I am sure that the team in our national digital certification agency will do its best to assure you about how seriously we are working to make users globally trusting our CA protected. Best regards, Taher Mestiri On Monday, 12 March 2018 15:59:55 UTC+1, Ryan Sleevi wrote: > These responses demonstrate why the request is troubling. They attempt to > paint it as "other people do it" > > The risk of removing an included CA must balance the ecosystem disruption > to those non-erroneous certs, while the risk to ecosystem inclusion needs > to balance both the aggregate harm to the ecosystem (through lowered > standards) and the risk to the ecosystem of rejecting the request (of > which, until inclusion is accepted, is low) > > The pattern of issues - particularly for a new CA - is equally problematic. > A CA, especially in light of the public discussions, should not be having > these issues in 2018, and yet, here we are. > > We are in agreement on the objective facts - namely, that there is a > prolonged pattern of issues - and the criteria - namely, that CAs should > adhere to the policy in requesting inclusion. A strict adherence to those > objectives would be to fully deny the request. It sounds like where we > disagree, then, is not in the objective facts and criteria, but rather, > where the evaluation of that leaves relative to risk. > > The position I am advocating is that, even if these individual matters > might be seen as less risky, especially, as has been mentioned, this CA is > "only" intended for .tn for the most case, the existence of such a pattern > (and the means of acknowledging-but-not-resolving-completely these issues) > is indicative that there will continue to be serious issues, and that the > risk is not simply limited to .tn, but threatens global Internet stability > and security. Given that the number of certificates being issued are, from > your own descriptions, aimed to be measured in the hundreds, further > highlights that the risk is rather substantial. > > On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi Ryan > > I am so sorry but is the same error. > > CN NAME NOT INCLUDE IN THE SAN > > Local IP ADRESS > > Policy not upto date > > Is clear for me and i understand. > > All this error became from approuved authority. Is the risk no. > > Then The ecosystem is not protected! > > ANIS > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
These responses demonstrate why the request is troubling. They attempt to paint it as "other people do it" The risk of removing an included CA must balance the ecosystem disruption to those non-erroneous certs, while the risk to ecosystem inclusion needs to balance both the aggregate harm to the ecosystem (through lowered standards) and the risk to the ecosystem of rejecting the request (of which, until inclusion is accepted, is low) The pattern of issues - particularly for a new CA - is equally problematic. A CA, especially in light of the public discussions, should not be having these issues in 2018, and yet, here we are. We are in agreement on the objective facts - namely, that there is a prolonged pattern of issues - and the criteria - namely, that CAs should adhere to the policy in requesting inclusion. A strict adherence to those objectives would be to fully deny the request. It sounds like where we disagree, then, is not in the objective facts and criteria, but rather, where the evaluation of that leaves relative to risk. The position I am advocating is that, even if these individual matters might be seen as less risky, especially, as has been mentioned, this CA is "only" intended for .tn for the most case, the existence of such a pattern (and the means of acknowledging-but-not-resolving-completely these issues) is indicative that there will continue to be serious issues, and that the risk is not simply limited to .tn, but threatens global Internet stability and security. Given that the number of certificates being issued are, from your own descriptions, aimed to be measured in the hundreds, further highlights that the risk is rather substantial. On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > I am so sorry but is the same error. > CN NAME NOT INCLUDE IN THE SAN > Local IP ADRESS > Policy not upto date > Is clear for me and i understand. > All this error became from approuved authority. Is the risk no. > Then The ecosystem is not protected! > ANIS > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi Ryan I am so sorry but is the same error. CN NAME NOT INCLUDE IN THE SAN Local IP ADRESS Policy not upto date Is clear for me and i understand. All this error became from approuved authority. Is the risk no. Then The ecosystem is not protected! ANIS ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Sat, Mar 10, 2018 at 7:03 PM, syrine.tl--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Trusting a CA is like that. Operating a CA requires a high degree of > > competence and excellence, and each CA applying for inclusion should be > as > > or more competent, as or more skilled, and as or more valuable, as they > > otherwise bring the ecosystem down rather than lifting it up. > > your effort lifting up CA ecosystem will not pay off by rejecting new CA > application. > Sure it is, when the CA has a pattern of misissuance. > You should also consider rejecting trusted CAs that still have > miss-issuance concerns despite their well-established certificate issuance > process and this is a fact. You have much more renewal request than new > inclusion > That has happened as well - if you look at PROCert for example. > If you do have a list of unacceptable auditors, it should be clearly > stated in Mozilla Policy so that all CAs will be informed. > Running through the archives is not considered an appropriate way of > information for a selection process as demanding as this. > This is covered in Section 2.3 of the Policy. > Having a fair and objective process requires applying the same acceptance > or rejection criteria to all CAs. > Otherwise it will be a double standards process. > Section 7.1 of the policy covers this. ""We will determine which CA certificates are included in Mozilla's root program based on the benefits and risks of such inclusion to typical users of our products. "" Inclusions are not guaranteed - they are a balancing act of risk. ""We will make such decisions through a public process, based on objective and verifiable criteria." It is objective and verified that the Tunisian Government has had a problematic series of misissuances, up to and including this past month, and has consistently failed to ensure proper controls are in place. Further, it is objective and verifiable, these were readily detectable by the Tunisian Government, but weren't noticed as such until the issue was raised. These included issues after the Tunisian Government reported them remediated. Further, based on does not mean limited to. ""We reserve the right to not include certificates from a particular CA in our root program."" Any root request can be rejected, for any reason, or not reason at all, at any time. > Anyway, we are looking forward to get the official outcome of Mozilla, and > we will spare no effort to be listed among Mozilla Trusted CA Can you explain your motivations for this? Such a globally trusted root carries with it profound security risk to the ecosystem. What is the overall goal for such trust, given that it does not in any way reduce risk of distrust. If anything, it increases the risk for all Subscribers and Relying Parties, given the pattern of misissuances shown and the apparent lack of technical expertise to support and protect that infrastructure. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Sat, Mar 10, 2018 at 2:55 PM, Anis via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Ryan > > just I want to remind you of these discussion and your opinion below > in some was different than you say here !!! > > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/CfyeeybBz9c > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/K3sk5ZMv2DE > > and > https://misissued.com/batch/1/ > > can you explain please > Anis I already have, but it seems you don't understand how a pattern of misissuance is problematic. I'm glad you agree that there's a pattern of misissuance, though - it does make it much easier to argue that the CA should not be trusted when there's agreement that they're not able to adhere to the Baseline Requirements. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi Ryan just I want to remind you of these discussion and your opinion below in some was different than you say here !!! https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/CfyeeybBz9c https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/K3sk5ZMv2DE and https://misissued.com/batch/1/ can you explain please Anis ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Saturday, March 10, 2018 at 4:57:43 PM UTC+1, Ryan Sleevi wrote: > On Fri, Mar 9, 2018 at 6:51 PM, syrine.tl--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > We do use another CA's tool to check the validity of CSR. As we do use the > > cr.sh tool developed also by another CA to check pre-certificate before > > issuance. So why is using a tool for checking CSR is problematic whereas > > using the crt.sh is approved ? The point here is to use an efficient tool > > to perform certificate checks regardless of the CA that owns it. Besides, > > given that the Tunisian government does not have a Mozilla trusted CA, we > > are forced to buy SSL certificates for Tunisian e-commerce websites from > > the CA who owns the CSR check tool that we use. > > In order to have a consistent RA process, we use the CSR check tool to by > > from that trusted CA and also to check our own certificates > > > > It is important to highlight here not that it's intrinsically bad to use > another tool - indeed, open-source and information sharing are good. The > point is that your own examination of your software and practices was so > deficient and lacking that you were unable to do even the most basic > operations of a CA correctly, and having misrepresented to Mozilla what > degree of checking you were doing. > > A CSR, however, is such a basic check that even limited technical > competency can do this. That this is relying on an online check is deeply > disappointing and highlights a lack of technical competency - which the > issues bore out - including the OCSP failures that seemingly still persist. > > Recall - the tool was written by a recently added CA, because they simply > read the specifications and wanted to ensure their systems followed them. > It would appear TunRootCA2 either did not read the specifications, or could > not be bothered to read them, or simply relies on off-the-shelf software to > be a CA - when so much more is expected. > > > > > Yet, at the same time, there are still-trusted CAs that have demonstrated > > > similar issues - although perhaps not to the same degree of becoming a > > > problematic pattern or an insufficient response - and they still remain > > > trusted. A recommendation to instill trust in such a new CA, one that has > > > demonstrated problematic patterns already, suggests that CAs may continue > > > to display such patterns without risk of distrust - which would overall > > be > > > harmful. Yet, if the recommendation is not to trust, what should the > > > remediation steps be to find a positive path forward? > > > > > > Since there are other still-trusted CAs that has the same problems, why is > > that the Tunisian CA treated with presumption of untrustworthiness . The > > decision-making process should be objective and fair for all CAs. > > > > You can see I specifically addressed that. To repeat: > 1) The Tunisian CA has demonstrated a problematic pattern of misissuance > and misconfiguration that has not, even until 2018-02-22, the most recent > review, stopped. > 2) If we believe in a fair and objective process, then the Tunisian CA will > make the ecosystem worse by accepting, by setting a new low bar of > competency and correctness. > > So, the fair and objective basis is to look at the pattern and trends - one > which would reasonably start a discussion of possible distrust - and simply > say the risk is not worth it. > > > > > I do not believe this CA should be trusted, given these patterns. I do > > not > > > feel the evidence supports a confident understanding of the critical role > > > that CAs play, nor an understanding of the technical risks and > > mitigations. > > > While it is good that TunRootCA2 has adopted practices such as linting, > > it > > > simply moves the problem to be more opaque - how many certificates fail > > > that check will not be known, nor will it be known how many failures are > > > now for policy reasons, rather than technical reasons. The community > > > largely relies on the information provided in audits - with the > > > expectations that CAs will self-report and self-disclose these issues - > > and > > > yet the audits not calling this information out is deeply worrying, both > > as > > > to quality and to completeness. > > > > During all the Mozilla review process, our team showed a willingness and > > a seriousness in the treatment of these incidents. We have implemented all > > the technical checks required to prevent the occurrence of other miss- > > issued certificates (pre-issuance linting). We have also reported all > > missiussed certificates of our root CA since its creation. There are in > > total 15 mississued certificates as listed Olfa's last message > > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/ > > fFcZ3SepAQAJ > > > Disclosure is not something that is exceptional - it is the minimum > required of a CA. The fact that new misissued certifica
Re: TunRootCA2 root inclusion request
On Fri, Mar 9, 2018 at 6:51 PM, syrine.tl--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > We do use another CA's tool to check the validity of CSR. As we do use the > cr.sh tool developed also by another CA to check pre-certificate before > issuance. So why is using a tool for checking CSR is problematic whereas > using the crt.sh is approved ? The point here is to use an efficient tool > to perform certificate checks regardless of the CA that owns it. Besides, > given that the Tunisian government does not have a Mozilla trusted CA, we > are forced to buy SSL certificates for Tunisian e-commerce websites from > the CA who owns the CSR check tool that we use. > In order to have a consistent RA process, we use the CSR check tool to by > from that trusted CA and also to check our own certificates > It is important to highlight here not that it's intrinsically bad to use another tool - indeed, open-source and information sharing are good. The point is that your own examination of your software and practices was so deficient and lacking that you were unable to do even the most basic operations of a CA correctly, and having misrepresented to Mozilla what degree of checking you were doing. A CSR, however, is such a basic check that even limited technical competency can do this. That this is relying on an online check is deeply disappointing and highlights a lack of technical competency - which the issues bore out - including the OCSP failures that seemingly still persist. Recall - the tool was written by a recently added CA, because they simply read the specifications and wanted to ensure their systems followed them. It would appear TunRootCA2 either did not read the specifications, or could not be bothered to read them, or simply relies on off-the-shelf software to be a CA - when so much more is expected. > > Yet, at the same time, there are still-trusted CAs that have demonstrated > > similar issues - although perhaps not to the same degree of becoming a > > problematic pattern or an insufficient response - and they still remain > > trusted. A recommendation to instill trust in such a new CA, one that has > > demonstrated problematic patterns already, suggests that CAs may continue > > to display such patterns without risk of distrust - which would overall > be > > harmful. Yet, if the recommendation is not to trust, what should the > > remediation steps be to find a positive path forward? > > > Since there are other still-trusted CAs that has the same problems, why is > that the Tunisian CA treated with presumption of untrustworthiness . The > decision-making process should be objective and fair for all CAs. > You can see I specifically addressed that. To repeat: 1) The Tunisian CA has demonstrated a problematic pattern of misissuance and misconfiguration that has not, even until 2018-02-22, the most recent review, stopped. 2) If we believe in a fair and objective process, then the Tunisian CA will make the ecosystem worse by accepting, by setting a new low bar of competency and correctness. So, the fair and objective basis is to look at the pattern and trends - one which would reasonably start a discussion of possible distrust - and simply say the risk is not worth it. > > I do not believe this CA should be trusted, given these patterns. I do > not > > feel the evidence supports a confident understanding of the critical role > > that CAs play, nor an understanding of the technical risks and > mitigations. > > While it is good that TunRootCA2 has adopted practices such as linting, > it > > simply moves the problem to be more opaque - how many certificates fail > > that check will not be known, nor will it be known how many failures are > > now for policy reasons, rather than technical reasons. The community > > largely relies on the information provided in audits - with the > > expectations that CAs will self-report and self-disclose these issues - > and > > yet the audits not calling this information out is deeply worrying, both > as > > to quality and to completeness. > > During all the Mozilla review process, our team showed a willingness and > a seriousness in the treatment of these incidents. We have implemented all > the technical checks required to prevent the occurrence of other miss- > issued certificates (pre-issuance linting). We have also reported all > missiussed certificates of our root CA since its creation. There are in > total 15 mississued certificates as listed Olfa's last message > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/ > fFcZ3SepAQAJ Disclosure is not something that is exceptional - it is the minimum required of a CA. The fact that new misissued certificates continued to be issued throughout the process, since its inception, shows a problem. That Baseline Requirements dates continued to be missed is equally problematic - and shows a process failure at an organization that is not mature enough yet to operat
Re: TunRootCA2 root inclusion request
On Friday, March 9, 2018 at 10:30:18 PM UTC+1, Ryan Sleevi wrote: > On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > This request has been in public discussion for more than 6 months, so I > > would like to make a decision soon. If you have comments or concerns with > > this request, please post them here by 6-March 2018. > > > Wayne, > > Thanks for encouraging this discussion and making sure it reaches a timely > conclusion. > > To assist in the review, I've tried to summarize the issues to date: > Incident 1: > - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson > noted incomplete reply to the list of Mozilla Problematic Practices > regarding DNS names appearing within the subjectAltName. In response, on > 2016-01-20, TunRootCA 2 replies - > https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they > only use the subjectAlternativeName. > - 2017-02-28: TunRootCA2 violates this requirement - > https://crt.sh/?id=99182607 > - 2017-03-03: TunRootCA2 revokes this certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 2: > - 2016-01-04: TunRootCA2 states their validation practices > - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121 > - 2016-03-21: TunRootCA2 revokes that certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 3: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address > with a validity period later than 2015-11-1. > - 2016-12-14: TunRootCA2 replaces the certificate > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > > Incident 4: > - 2012-07-01: Baseline Requirements effective date, with restrictions on > reserved IPs and internal server names. > - 2017-01-09: TunRootCA2 issues a certificate for an internal server name > - 2017-07-19: Charles Reiss raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ > - 2017-07-28: TunRootCA2 revokes this certificate > > During the discussion of these incidents, TunRootCA2 disclosed that RAs > handled domain name validation, and they used another CA's tools to check > the validity of CSRs. RAs were then empowered to issue the domain > information directly to cause issuance. This suggests a strong lack of > technical controls and understanding by RAs. In response, TunRootCA2 > indicated they were deploying a new PKI platform. > We do use another CA's tool to check the validity of CSR. As we do use the cr.sh tool developed also by another CA to check pre-certificate before issuance. So why is using a tool for checking CSR is problematic whereas using the crt.sh is approved ? The point here is to use an efficient tool to perform certificate checks regardless of the CA that owns it. Besides, given that the Tunisian government does not have a Mozilla trusted CA, we are forced to buy SSL certificates for Tunisian e-commerce websites from the CA who owns the CSR check tool that we use. In order to have a consistent RA process, we use the CSR check tool to by from that trusted CA and also to check our own certificates > On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain > validation, as per > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > > Incident 5: > - 2017-10-23: TunRootCA2 misissues again - > https://crt.sh/?id=242366304&opt=cablint > - 2018-02-22: Wayne Thayer raises this issue - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-27: TunRootCA2 revokes the certificate - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ > > Incident 6: > - 2018-02-22: Wayne Thayer completes initial review - > https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ > - 2018-02-23: TunRootCA2 misissues again - > https://crt.sh/?id=346579818&opt=cablint > - 2018-02-28: TunRootCA2 revokes the certificate > > > Like Jonathan, I am concerned about the technical controls instituted. From > this thread, it does not give the impression of a technically competent > organization. While the requirements for more detailed. While a number of > these incidents predate the normalized Mozilla Incident Report template ( > https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ
Re: TunRootCA2 root inclusion request
In addition to the issues Ryan has listed, during the root inclusion process multiple issues with their OCSP responder and CRL endpoints were observed and fixed only after the flaws were documented in the bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1233645). I believe any CA seeking inclusion should be capable of doing the sorts of checks the Mozilla community performs long prior to seeking root inclusion. Failures like this inspire no confidence in the technical acumen of the administrators and I do not believe this root inclusion request should be accepted. -Paul ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This request has been in public discussion for more than 6 months, so I > would like to make a decision soon. If you have comments or concerns with > this request, please post them here by 6-March 2018. Wayne, Thanks for encouraging this discussion and making sure it reaches a timely conclusion. To assist in the review, I've tried to summarize the issues to date: Incident 1: - 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson noted incomplete reply to the list of Mozilla Problematic Practices regarding DNS names appearing within the subjectAltName. In response, on 2016-01-20, TunRootCA 2 replies - https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they only use the subjectAlternativeName. - 2017-02-28: TunRootCA2 violates this requirement - https://crt.sh/?id=99182607 - 2017-03-03: TunRootCA2 revokes this certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 2: - 2016-01-04: TunRootCA2 states their validation practices - 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121 - 2016-03-21: TunRootCA2 revokes that certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 3: - 2012-07-01: Baseline Requirements effective date, with restrictions on reserved IPs and internal server names. - 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address with a validity period later than 2015-11-1. - 2016-12-14: TunRootCA2 replaces the certificate - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ Incident 4: - 2012-07-01: Baseline Requirements effective date, with restrictions on reserved IPs and internal server names. - 2017-01-09: TunRootCA2 issues a certificate for an internal server name - 2017-07-19: Charles Reiss raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ - 2017-07-28: TunRootCA2 revokes this certificate During the discussion of these incidents, TunRootCA2 disclosed that RAs handled domain name validation, and they used another CA's tools to check the validity of CSRs. RAs were then empowered to issue the domain information directly to cause issuance. This suggests a strong lack of technical controls and understanding by RAs. In response, TunRootCA2 indicated they were deploying a new PKI platform. On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain validation, as per https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ Incident 5: - 2017-10-23: TunRootCA2 misissues again - https://crt.sh/?id=242366304&opt=cablint - 2018-02-22: Wayne Thayer raises this issue - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ - 2018-02-27: TunRootCA2 revokes the certificate - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ Incident 6: - 2018-02-22: Wayne Thayer completes initial review - https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ - 2018-02-23: TunRootCA2 misissues again - https://crt.sh/?id=346579818&opt=cablint - 2018-02-28: TunRootCA2 revokes the certificate Like Jonathan, I am concerned about the technical controls instituted. From this thread, it does not give the impression of a technically competent organization. While the requirements for more detailed. While a number of these incidents predate the normalized Mozilla Incident Report template ( https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ ), it was designed precisely to address these issues, and the more recent replies do not provide particular reassurance that these incidents have been fully understood. The failures Wayne raised, particularly around documentation, are troubling. Equally troubling is that in the course of audits, these issues were not disclosed - or, if they were, the revocation of the certificate in response to these incidents was not disclosed to the broader community. Yet, at the same time, there are still-trusted CAs that have demonstrated similar issues - although perhaps not to the same degree of becoming a problematic pattern or an insufficient response - and they still remain trusted. A recommendation to instill trust in such a new CA, one that has demonstrated problematic patterns already, suggests that CAs may continue to display such patterns without risk of distrust - which would overall be harmful. Yet, if the recommendation is not to tru
Re: TunRootCA2 root inclusion request
Le mercredi 19 juillet 2017 10:10:19 UTC+1, Aaron Wu a écrit : > This request from the Government of Tunisia is to include the “Tunisian Root > Certificate Authority - TunRootCA2” root certificate, and enable the Websites > trust bit. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1233645 > > BR Self Assessment is here: > https://bugzilla.mozilla.org/attachment.cgi?id=8865381 > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8884764 > > * Root Certificate Download URL: > http://www.certification.tn/pub/TunRootCA2.crt > > * Documents are in French, translated in English > CP/CPS in French: > http://www.certification.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-05.pdf > > CP/CPS in English: > http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf > > > * CA Hierarchy: > This root will have internally-operated subordinate CAs. > Currently it has one internally-operated subordinate CA: > - Tunisian Server Certificate Authority - TunServerCA2 > > * This request is to turn on the Websites trust bit. EV treatment is not > requested. > > * CP/CPS of the Tunisian Server Certificate Authority PTC BR: > > ** Section 1.3.4: > “In the context of this CP / CPS, a Server Certificate Responsible (SCR) is a > natural person who is responsible for using the certificate of the server or > computer device identified in the certificate and the private key > corresponding to this certificate, on behalf of the entity identified in that > certificate. The SCR is contractually, hierarchically or legally bound to > this entity.” > > ** Section 3.2.2: > “Authentication of a client organization is done by checking the following > documents: > The certificate application form duly completed and signed by the applicant, > acting as a certificate request, containing in particular the postal address, > the professional e-mail address and the telephone number enabling the NDCA to > contact the future bearer; > • A copy of the National Identity Card, passport or residence card of the > applicant and the SCR; > • An extract from the trade register not exceeding three months; > The bearer must be informed that the personal identity information he has > provided for the registration file will be retained. > The verification and validation of the request are carried out in accordance > with the provisions described in section 4.2.” > > ** Section 4.2.1: > "For the purpose of verifying the identities of the applicants, the RA, > performs the following operations: > check the consistency of the registration dossier and the supporting > documents submitted; > verify the accuracy of the purchase order and payment; > verify that the organization holds the domain name by consulting the official > databases of AFRINIC or INTERNIC domain names, and > ensure that the SCR is aware of the terms and conditions applicable to the > use of the certificate. > Upon completion of these transactions, the RA sends the request to the CA > components responsible for certificate production. The RA then retains a copy > of the proof of identity submitted in paper or electronic form having a legal > value.” > > > * EV Policy OID: Not Requesting EV treatment > > * Test Websites > Valid certificate: https://valid-ov.certification.tn > Revoked certificate: https://revoked-ov.certification.tn > Expired certificate: https://expired-ov.certification.tn > > * CRL URLs: > http://crl.certification.tn/TunRootCA2.crl > http://crl.certification.tn/TunServerCA2.crl > CP/CPS section 2.3: A new CRL is published every 24 hours > > * OCSP URLs: > http://ocsp.certification.tn > OCSP responses have a maximum expiration time of 10 days. > > * Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 > for CA and BR audit criteria. > https://bug1233645.bmoattachments.org/attachment.cgi?id=8879910 > > > * Forbidden or Problematic Practices > (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices) > None Noted > > This begins the discussion of the request from the Government of Tunisia is > to include the “Tunisian Root Certificate Authority - TunRootCA2” root > certificate, and enable the Websites trust bit. > > I will greatly appreciate your constructive and thoughtful feedback on this > request. > > Aaron the inclusion of the certification authority in Mozilla is a challenge for the Tunisian government, efforts of more than 4 years of massive work, international audits, the improvement of this authority does not stop to prove the seriousness of the team that works day and night to succeed this challenge, despite the errors we read in this group, but I do not think they are so fatal compared to other errors of other certification authorities, I wish you give this authority a chance as you gave it to others. I found the responsiveness to answer you while r
Re: TunRootCA2 root inclusion request
Dear Jonathan, Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward. ==>All the misissued certificates have been revoked by the NDCA and new correct ones were substituted to the clients. The TunServerCA2 has been audited yearly by a qualified auditor (LSTI, France) since 2015. A new root will not resolve these problems because all of these issues are a part of the validation process in the RA. That’s why we implemented new technical controls in the TunServerCA2 RA to reject all the CSR that contain any problem of this kind. The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root. ==>Two technical controls have been implemented: 1. In the RA of the TunServerCA2, a specific coding has been done on the RA scripts. The Common Name specified in the CSR is, from now on, automatically included in the SAN entries. In addition to that, a control that ensures that the SAN entries contain the Common Name has been implemented. 2. An automatic check of TBS certificates using TBSCertificate crt.sh API has been added today and integrated into the issuance processes. Actually, we followed the suggestion of Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online published in https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4). There are a bunch of warnings, but these jumped out at me as being very serious: These certificates have a commonName that is not included as a dNSName SAN: - https://crt.sh/?id=99182607&opt=cablint ==>We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a code that includes automatically the Common Name in the SAN entries. Moreover, all the domain names declared in the certificate (CN and Subject Alternative Names) are checked by the RA according to the 3.2.2.4 of the CAB/Forum. - https://crt.sh/?id=242366304&opt=cablint ==>We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a coding that includes automatically the Common Name in the SAN entries. This certificate has a SAN with a domain ending in .local, which is a reserved special-use TLD: - https://crt.sh/?id=79470561&opt=cablint => We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved by updating our CSR checker to include the inspection of all the SAN entries declared in the CSR that contain a “.local” in CN or in any of the SAN entries. All of these cases are automatically rejected by the TunServerCA2 RA and the RSC has to generate a new correct CSR. It’s important to remember that these are only the certificates that we know about via CT. There may be certificates with similar or other issues that are not logged. ==> We have checked all the issued certificates by a daemon which integrates the crt.sh API. This daemon checked the issued certificates one by one in the RA database: There are 15 misissued certificates since the issuance of the TunServerCA2. You find below the serial number of each one, the Error reported by cablint, x509lint and zlint: 41591505131605113993BB051309A9A8 cablint WARNING Certificate Policies should not contain notice references cablint INFOTLS Server certificate identified x509lintWARNING explicitText is not using a UTF8String x509lintWARNING Policy information has qualifier other than CPS URI x509lintINFOSubject has a deprecated CommonName x509lintINFOUnknown validation policy zlint ERROR CAs must include keyIdentifer field of AKI in all non-self-issued certificates zlint ERROR CAs must support key identifiers and include them in all certificates zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue has been fixed after the first audit in august 2015. 41591509041609025C4CD135DDB18DDD cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint WARNING Special name in SAN cablint INFOTLS Server certificate identified x509lintWARNING explicitText is not using a UTF8Str
Re: TunRootCA2 root inclusion request
> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy > wrote: > > On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg > wrote: > >> >>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: This request has been in public discussion for more than 6 months, so I would like to make a decision soon. If you have comments or concerns >> with this request, please post them here by 6-March 2018. >>> >>> Given the misissued certificates in CT under the existing root, I >> believe this request should be rejected, and a new clean root with audits >> should be required before moving forward. >>> >> > This course of action doesn't seem consistent with our treatment of the > many included CAs that have experienced these problems. Given that revocation checking doesn’t work, and CT doesn’t provide a complete picture, especially without browser enforcement, accepting this root would have the result of exposing Mozilla's users to certificates that are known to be misissued. I realize that some inclusion requests have been accepted in the past despite existing misissued certificates, but I don’t think that is sufficient justification for continuing to do so. Why shouldn’t we require CAs to cut a new root when the data indicates that accepting the existing root will put users at risk? Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg wrote: > > > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> > >> This request has been in public discussion for more than 6 months, so I > >> would like to make a decision soon. If you have comments or concerns > with > >> this request, please post them here by 6-March 2018. > > > > Given the misissued certificates in CT under the existing root, I > believe this request should be rejected, and a new clean root with audits > should be required before moving forward. > > > This course of action doesn't seem consistent with our treatment of the many included CAs that have experienced these problems. > > The errors in the issued certificates indicate a lack of technical > controls in addition to improperly implemented certificate profiles. Given > this, an explanation should also be provided of what changes have been made > to the issuance environment to ensure these types of mistakes will not > happen under the new root. > > I just took a closer look at the thread, and it appears that some > misissuance was pointed out in July and most of the controls that were > suggested as a solution relied on humans. These controls appear to have > predictably failed, as multiple misissued certificates are from this fall, > well after the fixes should have been in place. > > Olfa's most recent response indicates that additional/technical controls were added this week. However, I'm not convinced that they are adequate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy > wrote: > > >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy >> wrote: >> >> This request has been in public discussion for more than 6 months, so I >> would like to make a decision soon. If you have comments or concerns with >> this request, please post them here by 6-March 2018. > > Given the misissued certificates in CT under the existing root, I believe > this request should be rejected, and a new clean root with audits should be > required before moving forward. > > The errors in the issued certificates indicate a lack of technical controls > in addition to improperly implemented certificate profiles. Given this, an > explanation should also be provided of what changes have been made to the > issuance environment to ensure these types of mistakes will not happen under > the new root. I just took a closer look at the thread, and it appears that some misissuance was pointed out in July and most of the controls that were suggested as a solution relied on humans. These controls appear to have predictably failed, as multiple misissued certificates are from this fall, well after the fixes should have been in place. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy > wrote: > > This request has been in public discussion for more than 6 months, so I > would like to make a decision soon. If you have comments or concerns with > this request, please post them here by 6-March 2018. Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward. The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root. There are a bunch of warnings, but these jumped out at me as being very serious: These certificates have a commonName that is not included as a dNSName SAN: - https://crt.sh/?id=99182607&opt=cablint - https://crt.sh/?id=242366304&opt=cablint This certificate has a SAN with a domain ending in .local, which is a reserved special-use TLD: - https://crt.sh/?id=79470561&opt=cablint It’s important to remember that these are only the certificates that we know about via CT. There may be certificates with similar or other issues that are not logged. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
This request has been in public discussion for more than 6 months, so I would like to make a decision soon. If you have comments or concerns with this request, please post them here by 6-March 2018. On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear Wayne, > > The TunRootCA2 root CA operates under the following CPS: > http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf > ==> The TunRootCA2 operates under a new version of the CP/CPS: : > http://www.certification.tn/sites/default/files/documents/ > CPCPS-NG-EN-02.pdf > > The TunserverCA2 subordinate CA operates under a different CPS: > http://www.certification.tn/sites/default/files/documents/ > CPCPS-PTC-BR-EN-05.pdf > ==> The TunServerCA2’s subordinate CA operates under a new version of > the CP/CPS : http://www.certification.tn/sites/default/files/documents/ > CPCPS-PTC-BR-EN-07.pdf > > These updated documents address the concerns I raised below. > > ==Good== > * Misissued certificates reported earlier in this thread have been revoked > ==> Yes. The RA of the TunServerCA2 has revoked all the misissued > certificates and issued new ones for its clients. > > ==Meh== > * Numerous warning level lint errors in issued certificates: > https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&; > minNotBefore=2017-01-01 > ==> 99182607 : The certificate has been issued on the 28th Feburary > 2017 and was revoked the 03rd of March 2017. > ==> 242366304 : The certificate has been issued on 25th October 2017 > and was revoked on the 02nd of November 2017. > ==>201192937 : This is the certificate of the OCSP server which checks > the status of the TLS/SSL certificates issued under TunServerCA2. > * From the US, the server is returning an error or taking more than one > minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl > (crt.sh is also timing out). > ==> This problem has been resolved. The reason of this slowness was > that during the last two weeks, we migrated to our new backup site. > * The great majority of certificates issued by this CA fall under the .tn > TLD; however, the Government of Tunisia has not requested that the root be > constrained to issuance for .tn names. > ==> Yes the great majority of certificates issued by this CA fall > under the .tn TLD. However, this CA also issues certificates under others > TLD like .com, .net and .org. > * The subordinate CA certificate contains no EKU extension so is not > constrained to issuing certain types of certificates. > ==> Yes, the subordinate CA certificate doesn’t contain a EKU > extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate. > This subordinate contains Certificate Sign and CRL Sign key usage. > > * Delegated 3rd parties are permitted. The CPS does not clearly state the > BR requirement that domain validation may not be performed by a delegated > third party. > ==> Yes the delegated 3rd parties are permitted. But, the domain > validation is only performed by the CRA of TunServerCA2 (see section > 1.3.2.2 of the new version of the CP/CPS). > * The only method of domain validation specified in the BR Self Assessment > is the now deprecated 3.2.2.4.5. How and when will the Government of > Tunisia comply with CA/Browser Forum ballot 218? > ==> See section 3.2.2 of the new version http://www.certification.tn/ > sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. > * The Government of Tunisia’s answer for wildcard domain validation in > their BR Self Assessment implies the use of method 3.2.2.4.1, but they > claim not to use that method in the same document. > ==> See section 3.2.2 of the new version http://www.certification.tn/ > sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. > * CPS section 4.9.2 does not permit a person who controls a domain name > contained in a certificate to request revocation unless they are the > Subscriber or the Subscriber's legal representative. > ==> Yes we confirm that TunServerCA2 does not permit that the person > who controls the domain name to request revocation. Only the subscriber and > the subscriber’s legal representative are allowed to request revocation. > > ==Bad== > * Missing SAN entries: https://crt.sh/?cablint=25&; > iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue > certificates, so the manual controls described earlier in this thread are > inadequate. > ==> To resolve the missing SAN entries, a specific coding has been > done this week on the RA scripts. The common name specified in the CSR is, > from now on, automatically included in the SAN entries. In addition to > that, a check of the issued certificate using the lintcert will be done by > the operators before delivering the certificate to the RSC. > I think you meant "SCR" (i.e. Subscriber) not "RSC". Please be aware that finding errors after a certificate is issued but before it is delivered to the SCR/Su
Re: TunRootCA2 root inclusion request
Dear Wayne, The TunRootCA2 root CA operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf ==> The TunRootCA2 operates under a new version of the CP/CPS: : http://www.certification.tn/sites/default/files/documents/CPCPS-NG-EN-02.pdf The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf ==> The TunServerCA2’s subordinate CA operates under a new version of the CP/CPS : http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf ==Good== * Misissued certificates reported earlier in this thread have been revoked ==> Yes. The RA of the TunServerCA2 has revoked all the misissued certificates and issued new ones for its clients. ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 ==> 99182607 : The certificate has been issued on the 28th Feburary 2017 and was revoked the 03rd of March 2017. ==> 242366304 : The certificate has been issued on 25th October 2017 and was revoked on the 02nd of November 2017. ==>201192937 : This is the certificate of the OCSP server which checks the status of the TLS/SSL certificates issued under TunServerCA2. * From the US, the server is returning an error or taking more than one minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is also timing out). ==> This problem has been resolved. The reason of this slowness was that during the last two weeks, we migrated to our new backup site. * The great majority of certificates issued by this CA fall under the .tn TLD; however, the Government of Tunisia has not requested that the root be constrained to issuance for .tn names. ==> Yes the great majority of certificates issued by this CA fall under the .tn TLD. However, this CA also issues certificates under others TLD like .com, .net and .org. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. ==> Yes, the subordinate CA certificate doesn’t contain a EKU extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate. This subordinate contains Certificate Sign and CRL Sign key usage. * Delegated 3rd parties are permitted. The CPS does not clearly state the BR requirement that domain validation may not be performed by a delegated third party. ==> Yes the delegated 3rd parties are permitted. But, the domain validation is only performed by the CRA of TunServerCA2 (see section 1.3.2.2 of the new version of the CP/CPS). * The only method of domain validation specified in the BR Self Assessment is the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia comply with CA/Browser Forum ballot 218? ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * The Government of Tunisia’s answer for wildcard domain validation in their BR Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use that method in the same document. ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * CPS section 4.9.2 does not permit a person who controls a domain name contained in a certificate to request revocation unless they are the Subscriber or the Subscriber's legal representative. ==> Yes we confirm that TunServerCA2 does not permit that the person who controls the domain name to request revocation. Only the subscriber and the subscriber’s legal representative are allowed to request revocation. ==Bad== * Missing SAN entries: https://crt.sh/?cablint=25&iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue certificates, so the manual controls described earlier in this thread are inadequate. ==> To resolve the missing SAN entries, a specific coding has been done this week on the RA scripts. The common name specified in the CSR is, from now on, automatically included in the SAN entries. In addition to that, a check of the issued certificate using the lintcert will be done by the operators before delivering the certificate to the RSC. ==> * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. ==> The revision dates of the subordinate CA CPS are: the 26th of June 2015, 28th of July 2015, 21st of October 2015, 21st of January 2016, 12th of February 2016, 18th of October 2016, 27th of November 2017 and 27th of February 2018. ==> The revision dates of the root CPS are : 01st of june 2015, 28th of july 2015 and 27th of November 2017. In the future, both of the TunRootCA2 and TunServerCA2 CPSs will be reviewed at least once a year to meet the requirement of the Mozilla pol
Re: TunRootCA2 root inclusion request
The TunrootCA2 root operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf I have reviewed the supplied BR Self Assessment, the CPSes, and related information, and have the following comments: ==Good== * Misissued certificates reported earlier in this thread have been revoked ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 * From the US, the server is returning an error or taking more than one minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is also timing out) * The great majority of certificates issued by this CA fall under the .tn TLD; however, the Government of Tunisia has not requested that the root be constrained to issuance for .tn names. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. * Delegated 3rd parties are permitted. The CPS does not clearly state the BR requirement that domain validation may not be performed by a delegated third party. * The only method of domain validation specified in the BR Self Assessment is the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia comply with CA/Browser Forum ballot 218? * The Government of Tunisia’s answer for wildcard domain validation in their BR Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use that method in the same document. * CPS section 4.9.2 does not permit a person who controls a domain name contained in a certificate to request revocation unless they are the Subscriber or the Subscriber's legal representative. ==Bad== * Missing SAN entries: https://crt.sh/?cablint=25&iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue certificates, so the manual controls described earlier in this thread are inadequate. * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. * The CPS does not comply with the BR requirement to document support for Certificate Authority Authorization (CAA). Has CAA been implemented? * The CPS does not describe how domain validation is performed and which of the BR methods are utilized as required by Mozilla policy section 2.2. * The CPS claims in section 4.2.1 that the databases of regional IP address registries are used to verify domain control. Please explain how this is possible. Next steps: 1. I would ask a representative of the Government of Tunisia to answer the above questions. 2. The CPS issues need to be corrected and new versions published. 3. Given the ongoing misissuance, I would not recommend approval of this request until pre-issuance linting has been implemented. Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi, please find at this URL the translation of the root CP/CPS. http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hello, It is mentioned in the page 9 section 1.1 that : The CA servers complies with the current version of the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (BR) published at http://www.cabforum.org. In the event of inconsistency between this document and the CAB Forum BR requirements, the CAB Forum BR requirements apply. " We will proceed to the transalation of the Root CP/CPS as soon as possible. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hello, I started reading your CP/CPS and I noticed that you do not use the standard CA/B Forum terminology. Is this on purpose? Is it just a translation issue? Furthermore, I believe that the English Root CA CP/CPS should be added to the bug, I can only find the translation of the SSL SubCA CP/CPS. And just a final note, I can't seem to be able to access the mail sent by Gerv the 15th of August (the one I'm replying to) at the google groups thread (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wCZsVq7AtUY). Maybe it got lost somehow and the CA contacts are using google groups to get an update on their discussion. Regards, Fotis On 15/08/2017 03:41 μμ, Gervase Markham via dev-security-policy wrote: > On 03/08/17 08:01, Olfa Kaddachi wrote: >> ==> Some of these controls are already in place (such as the field CN and >> Subject Alternative Name that does not contain a private IP address). > > That doesn't quite answer my question. > > Let me ask another way: for how long has the Government of Tunisia CA > been aware of the Baseline Requirements? From what date do you assert > that you have been compliant with these requirements? > >> 4- Validation of the technical data included in the CSR: The RA operator >> checks : >> >> Digital Signature Algorithm: SHA256 >> Key Algorithm: RSA >> Key Size: 2048 > > Why can such things not be checked programmatically? It seems you are > opening yourselves up to the possibility of human error. > >> Moreover, the NDCA is now implementing a new Managed PKI platform which will >> be in production by the end of September 2017. For the moment, the only >> improvement done, is the printing of all the subject alternative names in >> the certificate for the RA operators, in addition to the other fields (CN, >> O, OU, mail) in such a way that they can visually check all the fields >> before the delivery of the certificate. > > A visual check may not catch every problem. For example, would it catch > a trailing space? > >> >From what date would you say that your CA has been compliant with the CAB >> >Forum Baseline Requirements? >> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit >> performed by LSTI. The last audit took place from 27th to 30th September >> 2016 in applying the relevant ETSI Technical Specifications ETSI TS >> 102042v2.4.1. > > And that audit includes a BR audit? > > Did the audit report have any qualifications? > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- Fotis Loukos, PhD Director of Security Architecture SSL Corp e: fot...@ssl.com w: https://www.ssl.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On 03/08/17 08:01, Olfa Kaddachi wrote: > ==> Some of these controls are already in place (such as the field CN and > Subject Alternative Name that does not contain a private IP address). That doesn't quite answer my question. Let me ask another way: for how long has the Government of Tunisia CA been aware of the Baseline Requirements? From what date do you assert that you have been compliant with these requirements? > 4-Validation of the technical data included in the CSR: The RA operator > checks : > > Digital Signature Algorithm: SHA256 > Key Algorithm: RSA > Key Size: 2048 Why can such things not be checked programmatically? It seems you are opening yourselves up to the possibility of human error. > Moreover, the NDCA is now implementing a new Managed PKI platform which will > be in production by the end of September 2017. For the moment, the only > improvement done, is the printing of all the subject alternative names in the > certificate for the RA operators, in addition to the other fields (CN, O, OU, > mail) in such a way that they can visually check all the fields before the > delivery of the certificate. A visual check may not catch every problem. For example, would it catch a trailing space? >>From what date would you say that your CA has been compliant with the CAB >>Forum Baseline Requirements? > ==> The TunRootCA2 and TunServerCA2 passed two successive external audit > performed by LSTI. The last audit took place from 27th to 30th September 2016 > in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. And that audit includes a BR audit? Did the audit report have any qualifications? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Dear Gerv, Given that some of these are BR requirements, why were these controls not in place already? ==> Some of these controls are already in place (such as the field CN and Subject Alternative Name that does not contain a private IP address). In addition to that NDCA has implemented a procedure for the RA operators which include these sections: 1- Validation of the Organization - In case of a commercial and private organization: The RA operator checks the web site http://www.registre-commerce.tn. Then, he inserts the Tax Identification Number to verify the existence of the organization. - In the case of a public organization : The RA operator checks the web site http://www.infojort.com. Then, he inserts the Tax Identification Number to verify the existence of the organization. 2- Domain Validation : For the National domains, the RA operator checks the web site of the Tunisian Internet Agency which is responsible of the management of the national domain ".tn" and the IP addressing in Tunisia ( http://whois.ati.tn ). For the international domains, the RA operator checks the international whois. In both cases, the RA operator checks if the domain name is the property of the applicant. 3- CSR Validation The RA operator checks the CSR with this URL https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp 4- Validation of the technical data included in the CSR: The RA operator checks : Digital Signature Algorithm: SHA256 Key Algorithm: RSA Key Size: 2048 5- Validation of the data inserted in the CSR against the data filled in the form : Common name: Organization: Organizational unit: City/locality: State/province: Country: 6- Validation of the email : The RA operator checks if the email is in this form: ad...@domaine.com postmas...@domaine.com administra...@domaine.com webmas...@domaine.com 7- Validation of the information related to the legal person and the subscriber 8- Phone Call to the webmaster of the server Moreover, the NDCA is now implementing a new Managed PKI platform which will be in production by the end of September 2017. For the moment, the only improvement done, is the printing of all the subject alternative names in the certificate for the RA operators, in addition to the other fields (CN, O, OU, mail) in such a way that they can visually check all the fields before the delivery of the certificate. From what date would you say that your CA has been compliant with the CAB Forum Baseline Requirements? ==> The TunRootCA2 and TunServerCA2 passed two successive external audit performed by LSTI. The last audit took place from 27th to 30th September 2016 in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. The audit was performed by LSTI as a full audit. This audit confirms the validity of the certificate N° 11140 issued on November 2015 and valid until November 2018. The next full audit will be performed from 11th to 15th of September 2017. When will these improvements be implemented? And, given that these are only four possible ways a certificate can be messed up, what other checks are going to be implemented at the same time? ==> These improvements have already been implemented by our service provider during this week. The tests will be done from 14th to 25th of August 2017. The beginning of production is planned for the end of September after the audit. We already have other checks besides those four in our information system such as checking the fields in the CSR. These checks are already implemented. Olfa ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi Olfa, On 31/07/17 11:55, Olfa Kaddachi wrote: > 2) The deficiencies identified in those controls after the misissuance of > each of these certificates are essentially: > •controls on the field subject alternative names : > o this field must not contains private addresses > o this filed must not contain 127.0.0.1 address > o this filed must not contain a local FQDN > o this field must at least contain the CN Given that some of these are BR requirements, why were these controls not in place already? From what date would you say that your CA has been compliant with the CAB Forum Baseline Requirements? > 3) The implemented and planned improvements to the technical controls to > prevent these errors from happening again: When will these improvements be implemented? And, given that these are only four possible ways a certificate can be messed up, what other checks are going to be implemented at the same time? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi Jonathan, Please find below the description of the technical and organizational controls required: 1) The currently process of certificates issuance is composed by 4 steps: step 1: Registration process: This step consists of the verification of the following items: •the subscriber identify •the accuracy of the certificate requests (RA is using currently this URL to check the CSR https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp) •the possession of the domain names (who is, organization, validation phone,...) • After that, the RA operator insert all the required data in the RA interface, theses controls are implemented: •control of the syntax of the server name •control of the email of the server administrator •control of the identifier of the administrator •check of the CSR step2: Validation process: In this step, another registration operator (different of the first one), check all the inserted data. This check consists of the verification of inserted data against paper data. step3: Issuance of the certificate: In this step, the only control consists of the check of the data in the CSR against the inserted data. In the event of any error, the request is rejected. step4: Check of the issued certificate: In this step, another registration operator check the issued certificate before its delivery. 2) The deficiencies identified in those controls after the misissuance of each of these certificates are essentially: •controls on the field subject alternative names : o this field must not contains private addresses o this filed must not contain 127.0.0.1 address o this filed must not contain a local FQDN o this field must at least contain the CN 3) The implemented and planned improvements to the technical controls to prevent these errors from happening again: The NDCA is implementing a new system (Managed PKI solution) which includes such controls in different fields (CN, mail of administrator, check of CSR, check of subject alternative names, ...). Thanks Olfa ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
For reference, I’ve added crt.sh links for the replacement certificates below. > On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy > wrote: > > https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; > notAfter March 2017) issued by this CA which has a wildcard name in the > common name while the SAN contains specific domain names that would be > covered by the wildcard only. > > ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on > 2016-03-21 when the CA discover the mistake in the SAN extension. A new > certificate is issued on the same day (2016-03-21) with the right SAN > (*.sonede.com.tn). See the certificate below: > https://crt.sh/?id=15597407 > https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct > 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of > 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name > certs with validity past November 2015.) > > ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an > IPAddress SAN of 127.0.0.1. The new certificate for the end entity > (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See > certificate below: https://crt.sh/?id=180718609 > https://crt.sh/?id=79470561&opt=cablint is a certificate for the internal > name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017. > > ==> The CA proceeded to notify the end entity of the certificate > https://crt.sh/?id=79470561&opt=cablint. The certificate is revoked on > 28/07/2017 and replaced by a new certificate which does not contain in SAN > extension the internal name "adv-mail.calladvance.local". See ertificate > below: https://crt.sh/?id=180718608 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy > wrote: > > ==> The CA proceeded to notify the end entity of the certificate > https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new > certificate is issued by TunServerCA2.to this end entity. > > ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on > 2017-03-03 and issue a new one for the end entity > https://crt.sh/?id=99462700. The new certificate contains both names in SAN > (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at > the time of issuance, has verified that the Applicant had the right to use > and had the control of the both Domain Names. > > ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on > 2016-03-21 when the CA discover the mistake in the SAN extension. A new > certificate is issued on the same day (2016-03-21) with the right SAN > (*.sonede.com.tn). See the certificate below: > > ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an > IPAddress SAN of 127.0.0.1. The new certificate for the end entity > (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See > certificate below: > > ==> The CA proceeded to notify the end entity of the certificate > https://crt.sh/?id=79470561&opt=cablint. The certificate is revoked on > 28/07/2017 and replaced by a new certificate which does not contain in SAN > extension the internal name "adv-mail.calladvance.local". See ertificate > below: > > Olfa Kaddachi These incidents appear to demonstrate a lack of sufficient technical controls to prevent certificates from being issued with unvalidated and invalid data. Would you please describe: 1) the technical controls currently implemented in the issuance process; 2) the deficiencies identified in those controls after the misissuance of each of these certificates; 3) the implemented and planned improvements to the technical controls to prevent these errors from happening again. Thanks, Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
https://crt.sh/?id=21813439 is a certificate issued by this CA which has a domain name in the common name but only an email address in the SAN. (The certificate has TLS server/client usage EKUs.) ==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new certificate is issued by TunServerCA2.to this end entity. https://crt.sh/?id=99182607 is a revoked certificate issued by this CA which has a domain name in the common name which does not match the domain name in the SAN, which is for a different TLD. (A new certificate with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore which appears to have around the same timestamp as the revocation.) ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 2017-03-03 and issue a new one for the end entity https://crt.sh/?id=99462700. The new certificate contains both names in SAN (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at the time of issuance, has verified that the Applicant had the right to use and had the control of the both Domain Names. * https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; notAfter March 2017) issued by this CA which has a wildcard name in the common name while the SAN contains specific domain names that would be covered by the wildcard only. ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 2016-03-21 when the CA discover the mistake in the SAN extension. A new certificate is issued on the same day (2016-03-21) with the right SAN (*.sonede.com.tn). See the certificate below: -BEGIN CERTIFICATE- MIIGuTCCBKGgAwIBAgIQQVkWAyEXAyAwgwPw3/OEojANBgkqhkiG9w0BAQsFADB8 MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjAzMjEwMDAwMDBaFw0x NzAzMjAyMzU5NTlaMIHMMQswCQYDVQQGEwJUTjFBMD8GA1UECgw4U1RFIE5BVElP TkFMRSBEIEVYUExPSVRBVElPTiBFVCBERSBESVNUUklCVVRJT04gREVTIEVBVVgx KDAmBgNVBAsMH0RJUkVDVElPTiBDRU5UUkFMRSBJTkZPUk1BVElRVUUxGDAWBgNV BAMMDyouc29uZWRlLmNvbS50bjEmMCQGCSqGSIb3DQEJARYXd2VibWFzdGVyQHNv bmVkZS5jb20udG4xDjAMBgNVBAcMBVRVTklTMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAtUqxkjJGrnLQ+fx4vif+PV9FlwTByGoQ5F/2Kc67u9iM0zBt ttkcUHzdwoSkPLaYKezT3FQhuE7c1BKRBfne95zmDJ6kKbvoehUG6niJP6qOQ5p2 aT3oHPI87e20SQPFvvZMSbDftDq9/cH/69d+NkSlfAvihks7hp/zZv9QDdxaZh/O SfA12SRUy0/Q2n7VKnJrUPBK3Ydyl0KOS5p6LNxOUG4faJ9Fil3OO2b54etyMMcc QTiDqwDUXMohR3KzCQpUD9RGba41Stqwj7PO25YtNJbSSfCq5Sn9nZn8K9iapIDQ 1uwLO+VJf2SwEZl4iZulAhmXLieq/lv+oZreWQIDAQABo4IB5DCCAeAwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG AQUFBwMCMBoGA1UdEQQTMBGCDyouc29uZWRlLmNvbS50bjAfBgNVHSMEGDAWgBSH q/dpS1D2YVf/P1uOHXDGomyqxjA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vY3Js LmNlcnRpZmljYXRpb24udG4vVHVuU2VydmVyQ0EyLmNybDB7BggrBgEFBQcBAQRv MG0wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmNlcnRpZmljYXRpb24udG46ODA4 MDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL3B1Yi9U dW5TZXJ2ZXJDQTIuY3J0MIGnBgNVHSAEgZ8wgZwwgZkGCGCGFAECBgEIMIGMMCwG CCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL2NwczBcBggr BgEFBQcCAjBQMCwWJU5hdGlvbmFsIERpZ2l0YWwgQ2VydGlmaWNhdGlvbiBBZ2Vu Y3kwAwIBARogaHR0cHM6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9ycGEwDQYJKoZI hvcNAQELBQADggIBABUXwoV4YIrF4SVRUsb/dPhCO0uxcyVylVGz2y+OIDIsuy+d 7yJl4gCeLsMIIexWVqupnx1qzX8LR6ZMpVWbTeie0EFOppBU6S1OcFvf+6kQ9FNa RwCUn+fcYr5+NQRZD2OmfIeiqJ/vo0yNKQ2j5KENG1JZ8AgyeJ1RBK8IxAHNe9oE sdqjxXL54fh6t4zxfgavaRv9dZo+Ph4udEq1Ea/dKXg0pfsM1/bVpO+V1yaiL+lk fH/diGWUVV5HTlmtPCXU3idUKZytOWsP+NljHxQAmVzv38aAvvC9r2Dgc/MScCHP b7iBDDfwZRVj78MIAjHlf5cOAUCAJUmEC0lXnBNSRKAmYThCr+SVuKrqcwGcq5+X yNo46/ba6y/M/Q3TPCgDlFzgpxJ2Ox3jntSuA6qhLgJagC1HJce0wqAfCy4rAYuD WpsGr0rm65DSYgr+MZlcp4UNE1M+plKl7rXClYg5lRVX1c4glYr9+Do05z49ZRHq 1C8LpHbBYkDVbz/EsuDLZ+Y1wpo4Nec+PEfKm/Tc6Cyfr8JmHOhJ/YmaRg2UBh2q 1PE3gKyb5SZmmLmFBgwO5G91EvQOCSyuI/s7bzP5ra392q7Z9iFzadETjGjflWEq pMMUmphu3cCez871AUvDhMKKDlEdGob8Xw3RTwz485FuUdL8qb2vw36Jhhki -END CERTIFICATE- ** https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name certs with validity past November 2015.) ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an IPAddress SAN of 127.0.0.1. The new certificate for the end entity (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See certificate below: -BEGIN CERTIFICATE- MIIGqTCCBJGgAwIBAgIQQVkWEhQXEhOUxb2pudH/dDANBgkqhkiG9w0BAQsFADB8 MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjEyMTQwMDAwMDBaFw0x NzEyMTMyMzU5NTlaMIGkMQswCQYDVQQGEwJUTjEOMAwGA1UEChMFQ0VQRVgxHzAd BgNVBAsTFkRJUkVDVElPTiBDRU5U
Re: TunRootCA2 root inclusion request
On 07/19/2017 05:10 AM, Aaron Wu wrote: - Tunisian Server Certificate Authority - TunServerCA2 https://crt.sh/?id=79470561&opt=cablint is a certificate for the internal name 'adv-mail.calladvance.local' issued by this CA with a notBefore of 2017. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
On 07/19/17 05:10, Aaron Wu wrote: - Tunisian Server Certificate Authority - TunServerCA2 https://crt.sh/?id=21813439 is a certificate issued by this CA which has a domain name in the common name but only an email address in the SAN. (The certificate has TLS server/client usage EKUs.) https://crt.sh/?id=99182607 is a revoked certificate issued by this CA which has a domain name in the common name which does not match the domain name in the SAN, which is for a different TLD. (A new certificate with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore which appears to have around the same timestamp as the revocation.) https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; notAfter March 2017) issued by this CA which has a wildcard name in the common name while the SAN contains specific domain names that would be covered by the wildcard only. https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 127.0.0.1. (I believe that by 2014, the BRs prohibited issuing internal name certs with validity past November 2015.) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
