> -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Wednesday, June 21, 2017 4:16 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Root Store Policy 2.5: Call For Review and Phase-In Periods
> In your view, having an EKU limiting the intermediate to just SSL or to just > email makes it a technically constrained CA, and therefore not subject to > audit under any root program? The BRs clearly specify SSL CAs without name constraints are required to follow the BRs and must be audited. > I ask because Microsoft's policy at http://aka.ms/auditreqs says: > > "Microsoft requires that every CA submit evidence of a Qualifying Audit on > an annual basis for the CA and any non-limited root within its PKI chain." > > In your view, are these two intermediates, which are constrained only by > having the email and client auth EKUs, "limited" or "non-limited"? > Yes, I'd call these Secure mail CAs limited. > >>> The other customer complies the prior words in the Mozilla policy > >> regarding "Business Controls". > > By implication, and reading your previous emails, are you saying that the > first > customer does not comply with those words? The first customer does comply with "business Controls", in our view. We have contracts that specifies what they are allowed to do. > > That is correct. Enforcement is via contractual/business controls which is > compliant with the current policy, as vague and weak as that is (and you've > previously acknowledged). Moving from this level of control to being > audited or having name constraints will take more time that just a couple of > months. > > Leaving aside the requirements of other root programs, I agree this > arrangement with the second customer is compliant with our current policy. > For the new policy, they have 3 options: a) get an audit, b) use a name- > constrained intermediate, or c) move to a hosted service which limits them > to an approved set of domains. Agree, there are options for both of these customers and we're conformable we can make this happen within 12 months with another 12 months to keep the CA live for cert management and then doing a revocation of the CA. > Consistent with the principles outlined for Symantec regarding business > continuity, the fact that GlobalSign does not have the capability to provide > c) > should not be a factor in us determining how long we should allow this > particular situation to continue. > > It's worth noting that if we had discovered this situation for SSL - that an > unconstrained intermediate or uncontrolled power of issuance had been > given to a company with no audit - we would be requiring the intermediate > be revoked today, and probably taking further action as well. Agree > > Two further points: > > 1) It’s not clear of email applications work with name constrained CAs. > Some have reported email applications do not work, however, I have not > tested this case. > > That sounds like something you might want to investigate as a matter of > urgency :-) Are there any other CAs or mail vendors that have tested name constrained issuing CAs? If using name constrained CAs don’t work with some or all of the mail applications, it seems like we might as well recommend a change to the requirement. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
