RE: Suspicious test.com Cert Issued By GlobalSign
>Back in 2015, there were some GlobalSign testing in which users thought it was >acceptable to use domains like test.com and example.com for testing purposes. >Since this time, GlobalSign has implemented procedures to avoid any similar >situations in the future. Does it mean that GlobalSign allow RAs (trusted role employees) to add domain without necessary domain validation? Isn’t there any technical restriction that prevent this if the domain has not been validated, like having two different steps, and domain validation is the former step which cannot be overridden, than “adding a domain”? >As part of researching this reported misissuance, we've reviewed all orders >and certificates we've issued since this time to test.com and example.com and >found several orders in the pending or cancelled state. Is there any other domain that was thought to be allowed for testing purposes? Nio ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Suspicious test.com Cert Issued By GlobalSign
>Back in 2015, there were some GlobalSign testing in which users thought it was >acceptable to use domains like test.com and example.com for testing purposes. >Since this time, GlobalSign has implemented procedures to avoid any similar >situations in the future. Does it mean that GlobalSign allow RAs (trusted role employees) to add domain without necessary domain validation? Isn’t there any technical restriction that prevent this if the domain has not been validated, like having two different steps, and domain validation is the former step which cannot be overridden, than “adding a domain”? >As part of researching this reported misissuance, we've reviewed all orders >and certificates we've issued since this time to test.com and example.com and >found several orders in the pending or cancelled state. Is there any other domain that was thought to be allowed for testing purposes? Nio ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Include Renewed Kamu SM root certificate
On Wednesday, March 15, 2017 at 9:56:25 AM UTC-7, Kathleen Wilson wrote: > Thanks to those of you who have reviewed and commented on this request from > the Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM), to include > the "TUBITAK Kamu SM SSL Kok Sertifikasi - Surum 1" root certificate, and > enable the Websites trust bit. Thanks again to those of you who have reviewed this request, and to those of you who have participated in this discussion. I am now closing this discussion, and I will update the bug to recommend approval of this request. All further follow-up on this request should be in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262809 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On 16/03/17 11:25, douglas.beat...@gmail.com wrote: > For the record, we don't think it's necessary (or permissible) to > give employees (RAs) the power to add arbitrary domains to accounts > without proper vetting. I guess I'm still not being clear - sorry :-( Let me try one more time: Why does GlobalSign believe it is necessary for employees to have the technical capability to add arbitrary domains to accounts without going through ownership validation? I mean, clearly they did back in 2015, because that's exactly what happened. Do they still have the technical capability (ignoring policy and set procedures for a moment) or not? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Symantec: Next Steps
We have DTP and RA roles slated as part of the validation WG discussion, but only as they relate to validation. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, March 16, 2017 7:16 AM To: Gervase MarkhamCc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Symantec: Next Steps On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 09/03/17 13:32, Ryan Sleevi wrote: > > (Wearing Google hat only for this statement) Have you considered > > having this discussion in the CA/Browser Forum? > Google > > had planned to discuss this very topic at our upcoming F2F about how > > to address this, and would be very interested in collaborating with > > Mozilla > on > > this. I mentioned this recently to Kathleen at the WebTrust TF > > meetings, but apologies for not mentioning to you as well. > > This sounds like a good idea. Do we want to get this added in an open > slot? There may still be time. > Unconference future discussion. If CAs aren't interested in it, and it doesn't get discussed, then that seems like a suitable signal to discuss in the browser policies, doesn't it? > > I don't understand why you > > believe it's relevant the act of "Mozilla requiring disclosure of > > the audits". Can you help me understand where, in the policy, that's > required? > > I'm not sure where your text in quotes comes from, and nor can I work > out the referent of "it", so I don't understand this question. > The quoted text was attempting to summarize the following paragraph from you: """No, because in the case of a sub-CA, we require audits. And when we receive them, if they were done by unqualified parties, the CA would need to flag that, and we would make a judgement about that party's suitability at the time. The issue here arises that, because of the way things are set up, these RA's audits were not submitted to Mozilla, and so Symantec didn't have to resolve the Schrodinger's Cat of (qualified|not qualified and need us to make a judgement).""" The question here is that it seems you have hinged the acceptability/unacceptability of the auditor on the basis of whether or not it was required to be disclosed. Or, put differently, it sounds as if you suggest the only obligation a CA has to ensure their DTP auditors are qualified for the task at hand is if, and only if, Mozilla requests those audits. In the absence of that request, the CA is allowed to make their own individual determination. Further, it seems that you are suggesting that if a CA makes that determination, and it's incorrect, that's not a failure upon the CAs part, because they made 'a decision', and the relevant portions of Mozilla policy only apply to the 'next' audit. In effect, it makes the question of 'qualified' auditor one which can never look retrospectively to prevent issues or instill a duty of care, and it only applies forward thinking, to the 'next' audits. Or, put differently, it sounds as if you're suggesting that Symantec, having made a determination of qualified without input from Mozilla, has sufficiently abided by Mozilla's policy. I'm not sure that's a consistent read with the goals or policy stated. Rather, by making that determination without input from Mozilla, Symantec has instead taken on full liability for that audit. If, as in this case, evidence appears that suggests the auditor is not qualified, then the root issue rests with Symantec for not ensuring that the auditor was qualified. Similarly, all other CAs who are accepting audits from third-parties (whether DTPs or sub-CAs), and which are not ensuring those meet the definition of qualified, similarly accept risk of violation. That risk can be mitigated - for example, showing that the auditor is appropriately licensed at the time they conducted the audit, rejecting audits that are clearly problematic - but it's a risk born through exercising the capability to delegate. Put one last way (since this is such a thorny issue), I read your reply in the above quoted text to say "Mozilla requires that the CA make a decision. But it doesn't have to be a right one, and it doesn't have to use the same data we would." I'm trying to push back on that, which is every CA has an obligation to make the Right Decision - they have the tools at their disposal to do so, but uncertainty or perceived risk can and should only be mitigated by public consultation before - not after. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
Re: Symantec: Next Steps
On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 09/03/17 13:32, Ryan Sleevi wrote: > > (Wearing Google hat only for this statement) > > Have you considered having this discussion in the CA/Browser Forum? > Google > > had planned to discuss this very topic at our upcoming F2F about how to > > address this, and would be very interested in collaborating with Mozilla > on > > this. I mentioned this recently to Kathleen at the WebTrust TF meetings, > > but apologies for not mentioning to you as well. > > This sounds like a good idea. Do we want to get this added in an open > slot? There may still be time. > Unconference future discussion. If CAs aren't interested in it, and it doesn't get discussed, then that seems like a suitable signal to discuss in the browser policies, doesn't it? > > I don't understand why you > > believe it's relevant the act of "Mozilla requiring disclosure of the > > audits". Can you help me understand where, in the policy, that's > required? > > I'm not sure where your text in quotes comes from, and nor can I work > out the referent of "it", so I don't understand this question. > The quoted text was attempting to summarize the following paragraph from you: """No, because in the case of a sub-CA, we require audits. And when we receive them, if they were done by unqualified parties, the CA would need to flag that, and we would make a judgement about that party's suitability at the time. The issue here arises that, because of the way things are set up, these RA's audits were not submitted to Mozilla, and so Symantec didn't have to resolve the Schrodinger's Cat of (qualified|not qualified and need us to make a judgement).""" The question here is that it seems you have hinged the acceptability/unacceptability of the auditor on the basis of whether or not it was required to be disclosed. Or, put differently, it sounds as if you suggest the only obligation a CA has to ensure their DTP auditors are qualified for the task at hand is if, and only if, Mozilla requests those audits. In the absence of that request, the CA is allowed to make their own individual determination. Further, it seems that you are suggesting that if a CA makes that determination, and it's incorrect, that's not a failure upon the CAs part, because they made 'a decision', and the relevant portions of Mozilla policy only apply to the 'next' audit. In effect, it makes the question of 'qualified' auditor one which can never look retrospectively to prevent issues or instill a duty of care, and it only applies forward thinking, to the 'next' audits. Or, put differently, it sounds as if you're suggesting that Symantec, having made a determination of qualified without input from Mozilla, has sufficiently abided by Mozilla's policy. I'm not sure that's a consistent read with the goals or policy stated. Rather, by making that determination without input from Mozilla, Symantec has instead taken on full liability for that audit. If, as in this case, evidence appears that suggests the auditor is not qualified, then the root issue rests with Symantec for not ensuring that the auditor was qualified. Similarly, all other CAs who are accepting audits from third-parties (whether DTPs or sub-CAs), and which are not ensuring those meet the definition of qualified, similarly accept risk of violation. That risk can be mitigated - for example, showing that the auditor is appropriately licensed at the time they conducted the audit, rejecting audits that are clearly problematic - but it's a risk born through exercising the capability to delegate. Put one last way (since this is such a thorny issue), I read your reply in the above quoted text to say "Mozilla requires that the CA make a decision. But it doesn't have to be a right one, and it doesn't have to use the same data we would." I'm trying to push back on that, which is every CA has an obligation to make the Right Decision - they have the tools at their disposal to do so, but uncertainty or perceived risk can and should only be mitigated by public consultation before - not after. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On Thursday, March 16, 2017 at 6:59:41 AM UTC-4, Gervase Markham wrote: > Hi Doug, > > On 03/03/17 11:17, Gervase Markham wrote: > > That's lovely, but it doesn't answer my question. Let me restate it: why > > does GlobalSign believe it is necessary to give employees the power to > > add arbitrary domains to accounts without going through ownership > > validation? > Hi Gerv, For the record, we don't think it's necessary (or permissible) to give employees (RAs) the power to add arbitrary domains to accounts without proper vetting. This was a breakdown in the vetting process whereby this "test" domain was added in order to issue a certificate in production. When this was done the cert was revoked and the vetting for the domain was disabled. After this happened back in 2015 all of the RAs were instructed to follow production vetting procedures in production (obviously) and to not bend or break them when doing "testing". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA-1 serverAuth cert issued by Trustis in November 2016
Hi Blake, On 02/03/17 16:26, blake.mor...@trustis.com wrote: > We have engaged with our external auditors in relation to this and the > previous certificate that was reported. Once that activity has concluded we > will be providing further information. Do you have an ETA for this incident report? It's been quite some time now. I am still interested to understand how a "full investigation" of the first certificate failed to turn up the second. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
Hi Doug, On 03/03/17 11:17, Gervase Markham wrote: > That's lovely, but it doesn't answer my question. Let me restate it: why > does GlobalSign believe it is necessary to give employees the power to > add arbitrary domains to accounts without going through ownership > validation? You are getting various pings from me this morning :-) This question is still outstanding, and has been for a month now. Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
On 28/02/17 20:02, douglas.beat...@gmail.com wrote: > And lastly this ticket. The Domain name was validated in accordance > with the BRs, but there was a bug that allowed a user entered space > to be included in some of the SAN values. While the value is not > compliant with RFC 5280 or the BRs, there was no security issue with > the certificate that was issued (it was likely not able to secure the > intended subdomains). We'll provide an incident report for this. Hi Doug, Any news on when we might see this incident report? Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On 03/03/17 20:59, douglas.beat...@gmail.com wrote: > In general, when we receive new orders and issue certificates, the > vetting is done just prior to issuance time which permits the > certificate to be replaced up until expiration. We're looking into > cases where new "orders" may have used certificate data that was done > prior and then verifying that the domains (and enterprise data on the > subject DN) are re-verified at the applicable intervals. > > I'll send out an update as soon I have more information. Hi Doug, Any update? Once you report back, if nothing terrible is found, I think we can consider this matter resolved. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 16/03/17 10:50, Gervase Markham wrote: > https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership With these changes and the filing of https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this particular discussion RESOLVED. This means Mozilla plans to take no action against GTS based on what has been discovered and discussed. It doesn't mean people can't continue to make suggestions about improvements to our process, citing this situation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/17 16:20, Gervase Markham wrote: > On 09/02/17 22:55, Peter Bowen wrote: >> Policy Suggestion A) When transferring a root that is EV enabled, it >> should be clearly stated whether the recipient of the root is also >> receiving the EV policy OID(s). > > I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy Now done: "When transferring ownership of a root that is EV-enabled, it should be clearly stated whether the recipient of the root is also receiving the (right to use the) EV policy OID(s) and, if so, it should be confirmed that they have or will get the relevant audits before issuing EV certs." > Again, would this be covered by a requirement that no issuance was > permitted from a transferred root until all the paperwork was in place, > including appropriately-scoped audits? This might lead to a PITRA, but > would not have to. Now done: "No issuance whatsoever is permitted from a root certificate which has changed ownership by being sold by one company to another (as opposed to by acquisition of the owning company) until the receiving company has demonstrated to Mozilla that they have all the appropriate audits, CP/CPS documents and other systems in place. In addition, if the receiving company is new to the Mozilla root program, there must also be a public discussion regarding their admittance to the root program." https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 07/03/17 10:18, Gervase Markham wrote: > OK. Question for group: would it make sense to add the intermediate(s) > that GlobalSign is using for this purpose directly to the Mozilla trust > store, with the EV bit enabled, and then remove the EV bit from the > roots now owned by Google Trust Services? > > This would scope EV permissions more closely to the audits, and so > prevent Google from accidentally or intentionally issuing EV which was > shown as such in Firefox, without having an EV audit. Hearing no dissent, filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert BR violation
On 13/03/17 21:31, Jeremy Rowley wrote: > [JR] If you recall, I did try to change the policy. I was told to > change the RFC if I didn’t like the requirement. I find trying to > change the RFC nearly impossible as PKIX is dead and there are too > many other issues people would also like to change. If RFCs are unchangeably wrong, we should override them in the BRs. [citation needed] for the discussion where you were told to change the RFC; I'd like to read how that conversation went. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 08/03/17 15:06, Peter Bowen wrote: > By eliminating the DTP option, you will massively raise costs for CAs > that rely upon local translators and information gatherers. I think a > much better proposal would be to require the CA perform the RA > activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to > Subject Identity Information validation. Let's call that "Policy Proposal 5" :-) I think that if we did this, it might still make sense to enact Policy Proposal 1. I believe that would have the side effect of making sure we get all the audits. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Next Steps
On 09/03/17 13:32, Ryan Sleevi wrote: > (Wearing Google hat only for this statement) > Have you considered having this discussion in the CA/Browser Forum? Google > had planned to discuss this very topic at our upcoming F2F about how to > address this, and would be very interested in collaborating with Mozilla on > this. I mentioned this recently to Kathleen at the WebTrust TF meetings, > but apologies for not mentioning to you as well. This sounds like a good idea. Do we want to get this added in an open slot? There may still be time. > I'm not sure that we can or should so easily dismiss this with a suggestion > that we're dancing on the head of a pin here. That's not quite what I'm saying; I'm saying that my position could be seen as that (making very fine distinctions), and it possibly is. > I don't understand why you > believe it's relevant the act of "Mozilla requiring disclosure of the > audits". Can you help me understand where, in the policy, that's required? I'm not sure where your text in quotes comes from, and nor can I work out the referent of "it", so I don't understand this question. > I agree that removing the conflicting definition of qualified auditor is > likely a suitable outcome, and a much welcome improvement, but I do think > we owe it to the community to provide a greater degree of clarity then > currently provided by this thread about the expectations related to such > audits, both to the qualifications and the independence aspects. Surely requiring the auditor to be qualified in all cases will provide that clarity? I've filed https://github.com/mozilla/pkipolicy/issues/63 . Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy