Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
Ryan, Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responded Cert", how does you discussion in this thread relate to this? Are your responses here to a different question, because it appears (likely my misinterpretation) from this thread it's OK to include OCSP-signing into a CA certificate? https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ On Wednesday, September 4, 2019 at 11:01:36 AM UTC-4, Ryan Sleevi wrote: > On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > My question is the following: is it allowed to issue an OCSP Responder > > certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA > > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, > > > This will fail, not because of policy reasons, but because of technical > reasons (not Firefox). > > The code (for Firefox) is > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888 > , > with the most salient logic at > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884 > , > although the explanation in > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869 > explains > the technical reasons. > > > > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a > > possible, mandatory or forbidden option for such CAs? > > > > This is not forbidden by policy. That is, a technically constrained > subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth. > > As I see in the practice, if a technically constrained CA signs the OCSP > > response itself, it can be done without the "id-kp-OCSPSigning" EKU but > > with the "digitalSignature" KU bit in the CA certificate. > > > > Correct, if the id-kp-OCSPSigning EKU is missing from the technically > constrained intermediate, direct signing still works. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Which fields containing email addresses need to be validated?
On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote: > (Replying from the correct e-mail) > > On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > We should clarify the Mozilla policy to more clearly define list of fields > > containing email address (those 3 listed above) must be validated in > > section > > 2.2 so that this is clear and concise. > > > > Doug, > > Is the proposal that, similar to how TLS defines that domain names MUST > appear within the SAN:dNSName, that emailAddresses MUST appear within one > of those three fields (that is: subject:commonName, subject:emailAddress, > subjectAltName:rfc822Name), that any value in the subject MUST also appear > in the subjectAltName, and an emailAddress MUST NOT appear in any other > field? I agree with your description of where S/MIME email addresses must go, but I don't agree with your last statement that an email address "MUST NOT appear in any other field". More below. > That would address the concern, correct? > > Wayne opened this issue in December and I just replied with a comment > > related to the validation requirements of SAN/Other Name/UPN: > > > > https://github.com/mozilla/pkipolicy/issues/200 > > > I'm not sure I understand your question on this issue, and was hoping you > could expand. As you note, it's not used within S/MIME, so presumably, it's > not necessary for an S/MIME certificate, and thus MUST NOT be included. > That would resolve the ambiguity, correct? While it's not necessary for S/MIME, it's common to use an S/MIME certificate for both secure mail and client authentication (and even other things like ipSEC, file encryption etc). 1) Many/most CAs include both secure mail and client auth EKUs to permit such use. Is including the client auth EKU not permitted because it's not needed for S/MIME? 2) When using this S/MIME certificate for client authentication to a corporate system, the subjectAltName:UPN may be needed. The UPN typically contains an email address which may be the same, or may be different from the one in subjectAltName:rfc822Name. Since the UPN is not used for S/MIME, then its value should be opaque to S/MIME clients and the validation of this field should not need to follow the Mozilla policy for email validation. 3) Is including an email within a private extension not permitted, perhaps for a special usecase outside of S/MIME? 4) Is including an email address in any other subject field (there is a long list of subject fields in https://tools.ietf.org/html/rfc4519) not validated in accordance with the policy prohibited in S/MIME certificates? Since S/MIME applications use the email address only in the 3 fields you listed, is including it elsewhere an issue? Given there are no standards for the validation or use of an email address in any field (including the 3 used for S/MIME) when the secure mail EKU is NOT included, is there an issue when including email addresses in fields outside of those 3 when the certificate contains the secure mail EKU? I posted my proposed change to the Mozilla policy here: https://github.com/mozilla/pkipolicy/issues/200 Maybe this will be addressed as part of the S/MIME Certificate working group and we can wait until then. > Are you aware of any system that requires a single certificate contain both > in order to be used for S/MIME? If I understood your question right, it's > not required. No, not for S/MIME. Yes for when an S/MIME certificate is used for S/MIME and other purposes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Anomalous Certificate Issuances based on historic CAA records
Hi Quirin, I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged? We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded. We logged that there was no “issuewild” entry and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as “issue” at time of issuance. Doug On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote: > Hi Quirin, > > Thank you for your work on this topic. I would be grateful if you could > file Bugzilla bugs in the Misissuance component as follows, giving your > evidence of misissuance: > > On 22/11/17 23:50, Quirin Scheitle wrote: > > 1) Mix of wildcard and non-wildcard DNS names in SAN > > Batch: https://misissued.com/batch/32/ > > Description: best confer > > https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ > > One bug per CA, please. > > > 4) Apparent non-evaluation of CAA records > > Batch: https://misissued.com/batch/33/ > > Description: These cases appear as pretty straight-forward that they > > should not have been issued, but > > there might be good explanations > > One bug for the two Comodo certs, one for the Camerfirma cert. > > Thank you, > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On Monday, November 6, 2017 at 6:40:58 AM UTC-5, Ben Laurie wrote: > On 4 November 2017 at 19:54, Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 11/4/17 5:36 AM, Daniel Cater wrote: > > > > I think those CAs need to re-validate their recently issued SSL certs that > > contain any *.tg domains, and possibly revoke such certs and send us the > > info so corresponding entries can be added to OneCRL. But, as this is new > > to me, I will appreciate thoughtful and constructive input in this. > > > Since CT is not (yet) compulsory, it seems you probably have to contact all > CAs, doesn't it? Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? ___ 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)
Misissuance Report On February 25th 2017, we received a report that there was a SAN in an Incapsula OV certificate (specifically an OV certificate issued via the GlobalSign CloudSSL product) for a domain that is no longer registered (testsslfeb20.me). 1) GlobalSign CloudSSL product description To help clarify what we mean by GlobalSign CloudSSL product we wanted to describe the different operations CloudSSL customers can perform. CloudSSL supports New, Update, Reissue and Renew operations which all result in a new certificate being created. * New: We perform a manual organization validation on the initial CloudSSL OV certificate and CommonName. We assign a new OrderID. * Update: Customers can request the addition and removal of SANs. When a SAN is added, it is validated (in accordance with one of the approved domain validation methods) and then when the Update command is called, a new certificate with the requested changes is issued. The issued certificate has the same Subject DN, expiration date and OrderID. * Renew: When a CloudSSL order is renewed, it retains the same OrderID and Subject DN but the validity period is extended by 1-2 years. * Reissue: When a CloudSSL certificate is Reissued, it receives a new OrderID, but contains the same Subject DN, cert expiration date and SANs. * Revocation: The GlobalSign CA performs revocation by OrderID. This revokes all certificates in the Order which could be hundreds for CloudSSL orders. CloudSSL is the only GlobalSign SSL product where multiple certificates are issued against the same OrderID. In general, CloudSSL customers need large multi-domain SSL certificates which have SANs added and removed to support their changing customer needs. As such, updating certificates is a more frequent activity that with any other GlobalSign SSL products. 2) Incapsula certificates issued with testslsslfeb20.me We investigated this order and determined that this domain was verified when the certificate was first issued on 3/31/2014. While this order was issued and subsequently updated and reissued a number of times without breaking the 39 month certificate data re-use period, it’s clear that based on this report the domain is no longer controlled by Incapsula. At the conclusion of this analysis we revoked two OrderIDs that contained this SAN which resulted in the revocation of 26 certificates with this SAN. All unexpired certificates with this SAN are now revoked as can be seen on the page: https://crt.sh/?dNSName=testslsslfeb20.me 3) Research to verify all domains are being validated every 39 months After this initial review, we further investigated the time between the initial SAN approval and inclusion of the SAN in future certificates. We found that not all SANs have been validated within the prior 39 months due to a product bug. CloudSSL was not updated in February 2015 when the 39 month certificate data re-use policy was added to the BRs, thus domains were being included in reissued certificates without having updated domain verification checks performed. This product was launched in late 2011, so some SANs had reached their 39 month limit in February 2015, and some of those continued to be included in certificates through March 2017. 4) Resolution As soon as this was discovered, the system was patched on 3/16 to prevent additional certificates from being issued with SANs not validated within the prior 39 months. 5) Follow-up tasks The reporting interface and capabilities of the CA system to identify and revoke the impacted certificates was inadequate to properly locate impacted customers and OrderIDs which we needed to process. While some of them were identified and revoked relatively quickly, it took several weeks to set up a new database and reporting infrastructure which could be used to load and then correlate all of the certificates and SANs with the SAN approval dates and then notify customers and perform the revocations. Several rounds of reporting uploads, reporting and customer revocation updates were needed to completely capture the list of non-compliant certificates and revoke them. In summary the following are the final statistics: * 7 customers * 79 OrderIDs had certificates revoked * 945 unique SANs were included in certificates where the domain was not verified within the prior 39 months. * 905 Certificates were issued containing one or more SANs that has not been verified within the prior 39 months. These SANs were either removed from future certificates or they were re-validated. We've been actively working with 17 customers on 146 Orders and about 4000 SANs which expired on April 22 in order to comply with the 825 day data reuse policy. Checks were put in place to prevent certificates from being issued that contain SANs not validated within the prior 825 days prior to April 20th effective date. 6) Future Mitigation plans While we've put checks in
Re: Email sub-CAs
On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote: > On 13/04/17 14:23, Doug Beattie wrote: > > In 3.2 the term Technically Constrained is not defined to be any > > different than the BRs (or perhaps even less restrictive). > > You mean 2.3, right? Yes, 2.3. > I would say Inclusion section, bullet 9 gives the definition of > technically constrained. For email certs, because of the bug described > in issue #69, it basically just says that it has to have the > id-kp-emailProtection EKU. It should say more, but it doesn't. That's > problematic, because just having an EKU isn't really a technical > constraint in the "TCSC" sense. > > > In 3.2 > > this is all I can find regarding CAs that are capable of signing > > secure email certificates, section 9: "If the certificate includes > > the id-kp-emailProtection extended key usage, then all end-entity > > certificates MUST only include e-mail addresses or mailboxes that the > > issuing CA has confirmed (via technical and/or business controls) > > that the subordinate CA is authorized to use." > > > > There is no statement back to scope or corresponding audits. Were > > secure email capable CAs supposed to be disclosed and audited to > > Mozilla under 2.3? > > If they did not include id-kp-serverAuth, I would not have faulted a CA > for not disclosing them if they met the exclusion criteria for email > certs as written. OK. > > and how it applies to Secure email, I don't see how TCSCs with secure > > email EKU fall within the scope of the Mozilla Policy 2.3. Can you > > help clarify? > > I think this is basically issue #69. > https://github.com/mozilla/pkipolicy/issues/69 OK, I look forward to a conclusion on that. I hope that name constraining a secure email CA (either technically in the CA certificate or via business controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get us there then that would be acceptable. > I don't think it was supposed to be the case that intermediates with > id-kp-emailProtection alone were supposed to be considered TCSCs. After > all, certs with id-kp-serverAuth alone are not TCSCs; they need to have > Name Constraints as well. But you are right, that's what the policy says. > > > OK, you're right, the number of negatives in that section got me. > > So, even when EKU permits just secure email, having name constraints > > does not exempt a CA from the Mozilla policy. It does for BRs since > > email is not within scope (and discussed on the link you included in > > the response). When I saw TCSC references I personally didn't > > realize that this was different than the BR definition of TCSC (maybe > > should have called this something different). > > > > Section 3.1.2.1 specifies that any CA capable of issuing secure email > > certificates must have a "WebTrust for CAs" audit (or corresponding > > ETSI audit). This is a huge change from 3.2 and I wonder if all CAs > > understand this. Even the Blog about this version does not highlight > > this substantial change: > > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/ > > I didn't realise it _was_ a substantial change. Are you saying that you > used to think it was fine for email-only sub-CAs to have no audits at > all? Is this because you considered all such CAs to be TCSCs (by the > Mozilla definition)? Yes, we've been working hard to technically constrain all CAs and especially those operated outside of our infrastructure. We've been following the BR definition: Include EKUs in all CAs, and for those that include server auth or secure email, include name constraints. > Even if we didn't require it in our policy, I'm very surprised that > no-one else does. Which other root store policies have requirements on > email-only sub-CAs? Not that I know of. > > Obviously there are a lot of technically constrained CAs issued to > > organizations to run their own CAs for issuing secure email and > > client auth certificates. In order for them to continue operations > > they now every organization needs to be publicly reported and audited > > (a new requirement for 2.4.1 as far as I can tell), is that right? > > This is issue #36 :-) > https://github.com/mozilla/pkipolicy/issues/36 > > Do the CAs you are thinking of in this category have name constraints, > or not (either actually in the cert, or via business controls)? Yes - they are all either name constrained either via the certificate name constraints or via business controls. > > When did (does) this take effect? Is this for new CAs, existing or > > both? When would the Audit Period for these CAs need to begin? > > > > This is a side question, but does the Mozilla policy require that > > these CAs meet the Network Security Requirements? > > https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment. OK > > Section 5.3.2 says that all CAs of the type I'm discussing must be in > > the CCADB.
Re: GlobalSign BR violation
Attachment was stripped, here it the content: GlobalSign BR violation: EV Certificate with dNSName containing a space On February 26, 2017, we received a report that there were multiple SANs in an EV SSL Certificate that contained a space within it. Spaces are not permitted characters, per RFC 5280. We notified the customer on March 1, 2017 and revoked the certificate the next day on March 2, 2017. How this happened: A customer ordered a certificate with CN of m.vietnamairlines.com and requested 3 additional SANs as listed below. The base domain, “vietnamairlines.com”, was vetted and the certificate was then approved and issued. When they ordered this 2 year certificate in August 2015 they entered a space (likely via copy/paste) in the SAN fields and this was not obvious the vetting team when they were reviewing the request. Our ordering application did not properly strip out the spaces and the vetting team did not notice the space in the middle of these SANs. The result was this set of invalid SAN values: * owa. m.vietnamairlines.com * mail. m.vietnamairlines.com * autodiscover. m.vietnamairlines.com Scope of the problem: As part of this problem investigation, we went back and searched for DNSNames with characters that don’t comply with RFC 5280 in active certificates. We found 11 orders (each with 1 active certificate) that contained values non-compliant with the RFC and we found one order with 34 active certificates (due to many certificate updates/reissuances for this order). All have been revoked. In February 2016, we put in more comprehensive data validation for SANs and CNs and have not issued any non-compliant dNSName values in SSL Certificates since that time, until last week on March 21, 2017. We issued a Wildcard OV SSL Certificate with a SAN of the format www.*.domain.com. It has been since revoked. The issue here is that the updated logic released in February 2016 was not applied to a certain case for a certain language specific validation routines (we have unique server side validation routines for different languages and one was missed). Plans for Remediation: GlobalSign is continuing to improve automated compliance checking services to catch issues prior to issuance in a centralized location as a standard compliance process that all certificates will need to pass. In addition to checking data when we receive new orders, we will be adding independent, redundant checks as follows: * By the end of May 2017, we’ll be adding an independent post issuance check for 100% of issued SSL Certificates. This centralized check can be more robust and will proactively detect errors so we can address them immediately. * By the end of July 2017, we’ll be adding the same independent pre-issuance check in-line with the issuance process at the very last step prior to issuance to check issues before issuance. We feel that adding these 2 additional levels of checking we will eliminate issuance of certificates with CommonName and SAN values that do not comply with RFC 5280. We plan to add redundant pre- and post-issuance validation for additional fields later this year. ___ 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 Friday, March 17, 2017 at 5:37:38 AM UTC-4, Gervase Markham wrote: > On 16/03/17 17:20, douglas beattie wrote: > > Yes, RAs (trusted role employees) need to have the technical ability > > to manually add domains to accounts. They can verify domains in one > > of the 10 different methods and some of those involve manually > > looking in who-is for registrant info, using a DAD or in calling the > > contact. When one of these is used, we collect the vetting data then > > the RA can add/approve that domain. > > But is the addition of the domain gated on the > uploading/attachment/submission of what could plausibly be vetting data? It's gated on the RA following the correct process which is uploading the documents in one system and then approving the domain in a different system. > I mean, I understand you can't programmatically check that a person has > made a phone call. But you can require them to write a report of the > results of that phone call and not allow addition of the domain until > they've done it. Yes, they could just put "flibbertigibbet" into the > text box, but that at least shows they are deliberately bypassing the > process. > > If the addition is so gated, what did the employee in this case do? Did > they upload bogus data? No bogus data was uploaded. Doug ___ 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: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
I wanted to send out a short update of were we are on looking into the reported Incapusla/testslsslfeb20.me certificate and the thread of comments and questions above. In this specific case the domain was verified within 39 months of issuance/reissuance (no difference as Ryan pointed out). 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. Doug ___ 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 Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote: > Would it be possible to get a more precise answer other than "in accordance > with"? I am left to assume that in fact no verification was performed because > the previous verification was in the 39 month window. For this SSL product, customers place orders which are vetted to the OV level with normally just a single SAN. Once the order has been approved they can add SANs by verifying domain control via DNS or File based verificaton options. Over time they add and remove SANs as their customer base changes. They can re-issue the certificate which keeps the expiration date and the subject DN the same, but they add and remove SANs. In this case they did not remove SAN which are clearly not functional and are for domains which have expired. The reissueance process does not require the re-verification of the domain control, thus the certificate was reissued with these SANs. Subscribers are required to tell us when the certificate contents is no-longer accurate so appropriate action can be taken, but clearly this customer did not inform us. We'll be talking with them about this to find out why. Doug > > Original Message > From: douglas.beattie--- via dev-security-policy > Sent: Tuesday, February 28, 2017 6:46 AM > > ...snip... > > > I also would like to have an official reply from GlobalSign saying that "on > > the date they issue the certificate the domain exists". > > On the date that the certificate was issued it was verified in accordance > with the Domain Verification requirements in the BRs. > > Doug Beattie > GlobalSign > ___ > 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: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Tuesday, February 28, 2017 at 7:29:30 AM UTC-5, Itzhak Daniel wrote: > On Tuesday, February 28, 2017 at 1:38:25 PM UTC+2, Gervase Markham wrote: > > I think that without more evidence we must assume that GlobalSign > > validated this domain correctly at a time when it existed. > > There are many more test*.* domains, non of those (about 10) I checked exist. > I will compose a full list and reply. > > I also would like to have an official reply from GlobalSign saying that "on > the date they issue the certificate the domain exists". On the date that the certificate was issued it was verified in accordance with the Domain Verification requirements in the BRs. Doug Beattie GlobalSign ___ 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 Monday, February 27, 2017 at 11:04:53 AM UTC-5, Gervase Markham wrote: > Hi Doug, > > On 15/02/17 17:09, Gervase Markham wrote: > > But currently GlobalSign employees still are? > > > > If so, can you help us understand why that's necessary? Given that you > > control the domains used for testing, you should be able to set them up > > to auto-pass some form of automated validation, so imposing a validation > > requirement for every addition would not, at least on a superficial > > understanding, lead to increased friction in testing. > > It's been quite some time since this question was posed; when might you > have a response? Sorry, I missed the last request. As outlined above, this domain was added to this account for only a very short period of time and then it was removed, so it's no longer being used. Further, we've educated the groups involved that they must use real domains that are then properly verified in accordance with the CPS and BRs. > Thanks, > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
