Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don’t understand why you’re making a distinction as to CA certificates, > which are irrelevant with respect to the Delegated Responder profile. That > is, you’re trying to find a way that it’s compliant, but this introduction > of the CA bit as somehow special doesn’t have any basis, as far as I can > tell. > > The argument you're asserting is akin to someone saying that a CA > certificate with serverAuth EKU is mis-issued if the subject Common Name is > "Super Duper High Assurance Issuing CA", which is not a hostname in > preferred DNS syntax. After all, the EKU definition for serverAuth in RFC > 5280 states that certificates expressing that EKU value are used for TLS > server authentication, and clearly that is a malformed hostname so the > certificate can't be used for its intended purpose. In essence, the > argument you're presenting applies the end-entity profile definition to the > CA certificate profile for that EKU, which doesn't make sense. > I appreciate the comparison, but we both know that it's a flawed one. You're inventing a distinction - the CA bit - that doesn't exist, within the BRs or the RFCs. Nothing in the RFCs specifies the profile you describe for commonName. That's something the BRs do, and they explicitly do it contingent upon the CA bit (Subordinate CA vs Subscriber Cert) You're inventing a fiction that, no doubt, reflected a belief of some CAs when they did it. But no such distinction exists within the profiles, and it was, as far as I can tell, only Mozilla, and only in one of the three verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to profile things further. The distinction you make, about KU, falls apart when you realize the distinction you're making here, about CAs, is also made up. > > Where? It seems you’re reading this as inferred through omission of a > prohibition in Section 5.3, but you’re using it in the remainder of your > argument to argue why it’s proactively allowed. > > Ben's email from last evening [1] clearly stated that Mozilla has allowed > ocspSigning alongside other EKUs and the concrete example given was a CA > certificate that expresses the serverAuth and ocspSigning EKUs [2]. > Notably, this certificate also lacks the digitalSignature KU bit. > I think this is dangerously close to divination. Mozilla did not chase down non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla didn't enforce it, just like Microsoft didn't enforce their policy. That doesn't mean it was/is allowed by the BRs, and it doesn't mean that the non-compliance doesn't pose serious security risk. > > But I can’t get the view that says, even in 2020, that a Thing is Not a > Thing, which in this case is a Delegated Responder. Just like I can’t > understand folks who say a Sub-CA is not a Sub-CA if it’s a > Cross-Certificate. > > I think there's a world of difference between these two cases. In the > former case, there are technical controls for certificates used in a RFC > 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but > no digitalSignature KU bit will not have any OCSP responses created by the > CA trusted by clients. In the latter case, I entirely agree with you: the > only assurance that a "Cross-Certificate" can't be used to issue end-entity > certificates is pinky swears and promises and therefore must be treated as > a Sub-CA, because it technically is a Sub-CA. "will not have any OCSP responses created by the CA trusted by clients". I can literally show you the clients that do trust this, including Major Ones. Even Mozilla doesn't check the Key Usage - https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixocsp.cpp#127 We've already shown, however, that your argument about the "invalid" key usage is still a Mozilla Program Violation, in that it violates what you're declaring a defense mechanism (RFC 5280) by including an EKU not consistent with the extensions. This isn't a question about the BRs allowing such violations: they make no such statements. However, I'm more concerned by your latest message, in which you dismiss the very real security concern. That's something I think truly is dangerous here, especially for CAs following, because you're simply not correct to dismiss the concern. I also don't think it's correct to come up with a fiction that, because something not written in any spec (that responder certs are CA:FALSE) makes it OK to include the EKU to facilitate another behaviour not written in any spec (EKU chaining), and to do so ignoring both the RFC's profile (requiring KU) and the BRs profile (requiring nocheck). You're just making things up now. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
> I don’t understand why you’re making a distinction as to CA certificates, which are irrelevant with respect to the Delegated Responder profile. That is, you’re trying to find a way that it’s compliant, but this introduction of the CA bit as somehow special doesn’t have any basis, as far as I can tell. The argument you're asserting is akin to someone saying that a CA certificate with serverAuth EKU is mis-issued if the subject Common Name is "Super Duper High Assurance Issuing CA", which is not a hostname in preferred DNS syntax. After all, the EKU definition for serverAuth in RFC 5280 states that certificates expressing that EKU value are used for TLS server authentication, and clearly that is a malformed hostname so the certificate can't be used for its intended purpose. In essence, the argument you're presenting applies the end-entity profile definition to the CA certificate profile for that EKU, which doesn't make sense. > When you throw that out, it seems we’re in agreement here? If it’s problematic to have the wrong KU for the EKU with basicConstraints:CA=FALSE, it’s problematic to have the wrong KU for the EKU with basicConstraints:CA=TRUE. They’re both restrictions on key usage, and it doesn’t matter that one is a CA key. End-entity certificates and CA certificates will naturally have different KU values to constrain the allowed usages of the key. Again, the argument being presented here tries to assert that CA certificates need to fit the profile of the end-entity certificate for the corresponding EKU. >> Let's break this down: >> - RFC 5280 indicates that the digitalSignature KU is required for clients >> to verify signatures (e.g., OCSP response signatures) using the public key >> in the certificate >> - Mozilla Root Policy allows ocspSigning EKU in subCA certificates >> alongside other EKUs > Where? It seems you’re reading this as inferred through omission of a prohibition in Section 5.3, but you’re using it in the remainder of your argument to argue why it’s proactively allowed. Ben's email from last evening [1] clearly stated that Mozilla has allowed ocspSigning alongside other EKUs and the concrete example given was a CA certificate that expresses the serverAuth and ocspSigning EKUs [2]. Notably, this certificate also lacks the digitalSignature KU bit. >> Ignoring the KU, it appears that it is impossible to create a compliant CA certificate, despite it being allowed by Mozilla Policy. > Yes, it’s impossible to create an Issuing CA that has id-kp-OCSPSigning. That’s not a “bug” or the “gotcha” moment you seem to suggest: it’s the intended result! If Mozilla Root Policy has historically allowed this as was stated last evening, then surely there is some way to do it in a compliant manner. > But I can’t get the view that says, even in 2020, that a Thing is Not a Thing, which in this case is a Delegated Responder. Just like I can’t understand folks who say a Sub-CA is not a Sub-CA if it’s a Cross-Certificate. I think there's a world of difference between these two cases. In the former case, there are technical controls for certificates used in a RFC 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but no digitalSignature KU bit will not have any OCSP responses created by the CA trusted by clients. In the latter case, I entirely agree with you: the only assurance that a "Cross-Certificate" can't be used to issue end-entity certificates is pinky swears and promises and therefore must be treated as a Sub-CA, because it technically is a Sub-CA. Thanks, Corey [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/2WlxGVylBwAJ [2] https://crt.sh/?id=2472155 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 3, 2020 at 4:19 PM Peter Bowen wrote: > >> For the certificates you identified in the beginning of this thread, > >> we know they have a certain level of key protection - they are all > >> required to be managed using cryptographic modules that are validated > >> as meeting overall Level 3 requirements in FIPS 140. We also know > >> that there CAs are monitoring these keys as they have an obligation in > >> BR 6.2.6 to "revoke all certificates that include the Public Key > >> corresponding to the communicated Private Key" if the "Subordinate > >> CA’s Private Key has been communicated to an unauthorized person or an > >> organization not affiliated with the Subordinate CA". > > > > > > Sure, but we know that such revocation is largely symbolic in the > existence of these certificates for the vast majority of clients, and so > the security goal cannot be reasonably demonstrated while that Private Key > still exists. > > > > Further, once this action is performed according to 6.2.6, it disappears > with respect to the obligations under the existing auditing/reporting > frameworks. This is a known deficiency of the BRs, which you rather > comprehensively tried to address when representing a CA member of the > Forum, in your discussion about object hierarchies and signing actions. A > CA may have provisioned actions within 6.2.10 of their CPS, but that's not > a consistent baseline that they can rely on. > > > > At odds here is how to square with the CA performing the action, but not > achieving the result of that action? > > As long as the key is a CA key, the obligations stand. > Right, but we're in agreement that these obligations don't negate the risk posed - e.g. of inappropriate signing - right? And those obligations ostensibly end once the CA has revoked the certificate, since the status quo today doesn't require key destruction ceremonies for CAs. I think that latter point is something discussed in the CA/Browser Forum with respect to "Audit Lifecycle", but even then, that'd be difficult to work through for CA keys that were compromised. Put differently: If the private key for such a responder is compromised, we lose the ability to be assured it hasn't been used for shenanigans. As such, either we accept the pain now, and get assurance it /can't/ be used for shenanigans, or we have hope that it /won't/ be used for shenanigans, but are in an even worse position if it is, because this would necessitate revoking the root. It is, at the core, a gamble on the order of "Pay me now vs pay me later". If we address the issue now, it's painful up-front, but consistent with the existing requirements and mitigates the potential-energy of a security mistake. If we punt on the issue, we're simply storing up more potential energy for a more painful revocation later. I recognize that there is a spectrum here on options. In an abstract sense, the calculus of "the key was destroyed a month before it would have been compromised" is the same as "the key was destroyed a minute before it would have been compromised" - the risk was dodged. But "the key was destroyed a second after it was compromised" is doom. > > Pedro's option is to reissue a certificate for that key, which as you > point out, keeps the continuity of CA controls associated with that key > within the scope of the audit. I believe this is the heart of Pedro's risk > analysis justification. > > - However, controls like you describe are not ones that are audited, > nor consistent between CAs > > - They ultimately rely on the CA's judgement, which is precisely the > thing an incident like this calls into question, and so it's understandable > not to want to throw "good money after bad" > > To be clear, I don't necessarily see this as a bad judgement on the > CA's part. Microsoft explicitly documented that _including_ the OCSP > EKU was REQURIED in the CA certificate if using a delegated OCSP > responder (see > https://support.microsoft.com/en-us/help/2962991/you-cannot-enroll-in-an-online-certificate-status-protocol-certificate > ). > Using a delegated OCSP responder can be a significant security > enhancement in some CA designs, such as when the CA key itself is > stored offline. > Oh, I agree on the value of delegated responders, for precisely that reason. I think the bad judgement is not trying to find an alternative solution. Some CAs did, and I think that highlights strength. Other CAs, no doubt, simply said "Sorry, we can't do it" or "You need to run a different platform" I'm not trying to suggest bad /intentions/, but I am trying to say that it's bad /judgement/, no different than the IP address discussions had in the CA/B Forum or internal server names. The intentions were admirable, the execution was inappropriate. > > The question of controls in place for the lifetime of the certificate is > the "cost spectrum" I specifically talked about in >
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 3, 2020 at 9:18 AM Ryan Sleevi wrote: > > > > On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote: >> >> While it may be viewed as best practice to have short lived responder >> certificates, it must not be viewed as a hard requirement for the BRs >> or for the Mozilla program. As you have pointed out previously, a >> browser could make this a requirement, but I am unaware of any >> publicly available requirement ot do so. > > > Thanks, and I think you're making a useful clarification here. The 'need' > being talked about is the logical consequence of a secure design, and the > assumptions that go with it, as well as the role the BRs play in "profiling > down" RFC 5280-and-related into sensible subsets appropriate for their use > case. > > I think we're in agreement here that nocheck is required, and that the > consequences of nocheck's presence, namely: > CAs issuing such a certificate should realize that a compromise of > the responder's key is as serious as the compromise of a CA key > used to sign CRLs, at least for the validity period of this > certificate. CAs may choose to issue this type of certificate with > a very short lifetime and renew it frequently. > > As BR-consuming clients, the majority of implementations I looked at don't > recursively check revocation for the delegated responder. That is, rather > than "nocheck" determining client behaviour (vs its absence), "nocheck" is > used to reflect what the clients will do regardless. This can be > understandably seen as 'non-ideal', but gets back into some of the discussion > with Corey regarding profiles and client behaviours. So we are in agreement that is a certificate consumer bug if it fails to check revocation on certificates that do not have nocheck set. (Yes, I know that is a massive set of negations, sorry.). Good news is that all the certificates are in the category of "need revocation checking". >> > It seems we’re at an impasse for understanding the issue for >> > internally-operates Sub CAs: this breaks all of the auditable controls and >> > assurance frameworks, and breaks the security goals of a “correctly” >> > configured delegated responder, as discussed in the security considerations >> > throughout RFC 6960. >> >> This is where I disagree. Currently CAs can create as many delegated >> OCSP responder certificates as they like with as many distinct keys as >> they like. There are no public requirements from any browser on the >> protection of OCSP responder keys, as far as I know. The few >> requirements on revocation information are to provide accurate >> information and provide the information within 10 seconds "under >> normal operating conditions" (no SLO if the CA determines it is not >> operating under normal conditions). > > > I suspect this is the reopening of the discussion about "the CA organization" > or "the CA certificate"; does 6.2.7 apply to all Private Keys that logically > make up the CA "the organization"'s services, or is 6.2.7 only applicable to > keys with CA:TRUE. Either extreme is an unsatisfying answer: do the TLS keys > need to be on FIPS modules? (no, ideally not). Does this only apply to CA > keys and not to delegated responders (no, ideally not). As I read the BRs today, the requirement only applies to CA keys and not to keys for delegated responders. However that does not matter in this case, because all the certificates you identified are for CAs, so we know their keys are in HSMs. > Going back to 6960 and the requirement of pkix-nocheck, we know that such a > responder certificate is 'as powerful as' the Private Key associated with the > CA Certificate for which the responder is a responder for. Does the > short-lived validity eliminate the need for protection? > > I suspect when you disagree, is with respect to the auditable > controls/assurance frameworks, and less with respect to security goals > captured in 6960, since we seemed to agree on those above. > >> >> For the certificates you identified in the beginning of this thread, >> we know they have a certain level of key protection - they are all >> required to be managed using cryptographic modules that are validated >> as meeting overall Level 3 requirements in FIPS 140. We also know >> that there CAs are monitoring these keys as they have an obligation in >> BR 6.2.6 to "revoke all certificates that include the Public Key >> corresponding to the communicated Private Key" if the "Subordinate >> CA’s Private Key has been communicated to an unauthorized person or an >> organization not affiliated with the Subordinate CA". > > > Sure, but we know that such revocation is largely symbolic in the existence > of these certificates for the vast majority of clients, and so the security > goal cannot be reasonably demonstrated while that Private Key still exists. > > Further, once this action is performed according to 6.2.6, it disappears with > respect to the obligations under the
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 3, 2020 at 10:57 AM Peter Bowen wrote: > While it may be viewed as best practice to have short lived responder > certificates, it must not be viewed as a hard requirement for the BRs > or for the Mozilla program. As you have pointed out previously, a > browser could make this a requirement, but I am unaware of any > publicly available requirement ot do so. > Thanks, and I think you're making a useful clarification here. The 'need' being talked about is the logical consequence of a secure design, and the assumptions that go with it, as well as the role the BRs play in "profiling down" RFC 5280-and-related into sensible subsets appropriate for their use case. I think we're in agreement here that nocheck is required, and that the consequences of nocheck's presence, namely: CAs issuing such a certificate should realize that a compromise of the responder's key is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently. As BR-consuming clients, the majority of implementations I looked at don't recursively check revocation for the delegated responder. That is, rather than "nocheck" determining client behaviour (vs its absence), "nocheck" is used to reflect what the clients will do regardless. This can be understandably seen as 'non-ideal', but gets back into some of the discussion with Corey regarding profiles and client behaviours. "need" isn't an explicitly spelled out requirement, I agree, but falls from the logical consequences of designing such a system and ensuring equivalent security properties. For example, consider 4.9.10's requirement that OCSP responses for subordinate CA certificates not have a validity greater than 1 year (!!). We know that's a clear security goal, and so a CA needs to ensure they can meet that property. If issuing a Delegated Responder, it logically follows that its validity period should be a year or less, because if that Delegated Responder is compromised, the objective of 4.9.10 can't be fulfilled. I agree that a CA might argue "well, we published a new response, and 4.9.10 doesn't say anything about having to result, just perform the action", but I think we can agree that such an approach, even if technically precise, calls into question much of their overall interpretation of the BRs. > > It seems we’re at an impasse for understanding the issue for > > internally-operates Sub CAs: this breaks all of the auditable controls > and > > assurance frameworks, and breaks the security goals of a “correctly” > > configured delegated responder, as discussed in the security > considerations > > throughout RFC 6960. > > This is where I disagree. Currently CAs can create as many delegated > OCSP responder certificates as they like with as many distinct keys as > they like. There are no public requirements from any browser on the > protection of OCSP responder keys, as far as I know. The few > requirements on revocation information are to provide accurate > information and provide the information within 10 seconds "under > normal operating conditions" (no SLO if the CA determines it is not > operating under normal conditions). > I suspect this is the reopening of the discussion about "the CA organization" or "the CA certificate"; does 6.2.7 apply to all Private Keys that logically make up the CA "the organization"'s services, or is 6.2.7 only applicable to keys with CA:TRUE. Either extreme is an unsatisfying answer: do the TLS keys need to be on FIPS modules? (no, ideally not). Does this only apply to CA keys and not to delegated responders (no, ideally not). Going back to 6960 and the requirement of pkix-nocheck, we know that such a responder certificate is 'as powerful as' the Private Key associated with the CA Certificate for which the responder is a responder for. Does the short-lived validity eliminate the need for protection? I suspect when you disagree, is with respect to the auditable controls/assurance frameworks, and less with respect to security goals captured in 6960, since we seemed to agree on those above. > For the certificates you identified in the beginning of this thread, > we know they have a certain level of key protection - they are all > required to be managed using cryptographic modules that are validated > as meeting overall Level 3 requirements in FIPS 140. We also know > that there CAs are monitoring these keys as they have an obligation in > BR 6.2.6 to "revoke all certificates that include the Public Key > corresponding to the communicated Private Key" if the "Subordinate > CA’s Private Key has been communicated to an unauthorized person or an > organization not affiliated with the Subordinate CA". > Sure, but we know that such revocation is largely symbolic in the existence of these certificates for the vast majority of clients, and so the security goal
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Ryan, I have read through this thread and am also somewhat perplexed. I want to be clear, I'm posting only for myself, as an individual, not on behalf of any current or former employers. On Fri, Jul 3, 2020 at 4:26 AM Ryan Sleevi via dev-security-policy wrote: > On Fri, Jul 3, 2020 at 3:24 AM Pedro Fuentes via dev-security-policy > wrote: > > > > > > > Yes. But that doesn't mean we blindly trust the CA in doing so. And that's > > > the "security risk". > > > > But the point then is that a delegated responder that had the required > > "noCheck" extension wouldn't be affected by this issue and CAs wouldn't > > need to react, and therefore the issue to solve is the "mis-issuance" > > itself due to the lack of the extension, not the fact that the CA > > certificate could be used to do delegated responses for the same operator > > of the Root, which is acceptable, as you said. > > > I don’t understand why this is difficult to understand. If you have the > noCheck extension, then as RFC 6960, you need to make that certificate > short lived. The BRs require the cert have the extension. I think this is difficult to understand because you are adding requirements that don't currently exist. There is nothing in the BRs or other obligations of the CA to make a delegated OCSP responder certificate short-lived. From 6960: "CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently." 6960 explicitly says "may" is defined in RFC 2119, which says: "MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional." Contrast with "should" which is "This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." While it may be viewed as best practice to have short lived responder certificates, it must not be viewed as a hard requirement for the BRs or for the Mozilla program. As you have pointed out previously, a browser could make this a requirement, but I am unaware of any publicly available requirement ot do so. > Similarly, if something goes wrong with such a responder, you also have to > consider revoking the root, because it as-bad-as a root key compromise. I think we can all agree to this point. > In fact the side effect is that delegated responders operated externally > > that have the required no check extension don't seem to be affected by the > > issue and would be deemed acceptable, without requiring further action to > > CAs, while the evident risk problem is still there. > > > The “nocheck” discussion extension here is to highlight the compliance > issue. > > The underlying issue is a security issue: things capable of providing OCSP > responses that shouldn’t be. > > It seems you understand the security issue when viewing external sub-CAs: > they can now impact the security of the issuer. > > It seems we’re at an impasse for understanding the issue for > internally-operates Sub CAs: this breaks all of the auditable controls and > assurance frameworks, and breaks the security goals of a “correctly” > configured delegated responder, as discussed in the security considerations > throughout RFC 6960. This is where I disagree. Currently CAs can create as many delegated OCSP responder certificates as they like with as many distinct keys as they like. There are no public requirements from any browser on the protection of OCSP responder keys, as far as I know. The few requirements on revocation information are to provide accurate information and provide the information within 10 seconds "under normal operating conditions" (no SLO if the CA determines it is not operating under normal conditions). For the certificates you identified in the beginning of this thread, we know they have a certain level of key protection - they are all required to be managed using cryptographic modules that are validated as meeting overall Level 3 requirements in FIPS 140. We also know that there CAs are monitoring these keys as they have an obligation in BR 6.2.6 to "revoke all certificates that include the Public Key corresponding to the communicated Private Key" if the "Subordinate CA’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA". I agree with Pedro here. If the CA has control over the keys in the certificates in question, then I do not see that there is a risk that is greater than already exists. The CA can determine that these are approved OCSP responders and easily assess whether they have controls in place since the creation of the certificate that provide assurance that all OCSP responses signed using the key were accurate (if any such responses exist). They can also easily validate that they have controls around these keys to provide assurance that any future OCSP responses signed using the key
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 3, 2020 at 10:04 AM Arvid Vermote wrote: > GlobalSign recognizes the reported security issue and associated risk, and > is working on a plan to remediate the impacted CA hierarchies with first > priority on terminating those branches that include issuing CA with private > keys outside of GlobalSign's realm. We will soon share an initial plan on > our Bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1649937. > > One question we have for the root store operators specifically is what type > of assurance they are looking for on the key destruction activities. In the > past we've both done key destruction ceremonies without and with (e.g. in > the case of addressing a compliance issue like > https://bugzilla.mozilla.org/show_bug.cgi?id=1591005) an external auditor > witnessing the destruction and issuing an independent ISAE3000 witnessing > report. Since the goal here is to be able to demonstrate, with some reasonable assurance, that this key will not come back and haunt the ecosystem, my intent of the suggestion was yes, an independently witnessed ceremony with an appropriate report to that fact (e.g. ISAE300) The reason for this is that so much of our current design around controls and audits assume that once something is revoked, the key can no longer do harm and is not interesting if it gets compromised. This threat model defeats that assumption, because for the lifetime of the responder certificate(s) associated with that key, it can be misused to revoke itself, or its siblings, and cause pain anew. I suspect that the necessity of destruction ceremony is probably influenced by a variety of factors, such as how long the responder cert is valid for. This is touched on some in RFC 6960. I don’t know what the “right” answer is, but my gut is that any responder cert valid for more than a year from now would benefit from such a report. If it’s less than a year out, and internally operated, that maybe is reasonable to not require a report? I’m not sure where that line is, and this is where the CAs can share their analysis of the facts to better inform and find the “right” balance here. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 3, 2020 at 8:06 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan, > I don’t think I’m failing to see the security problem, but we evidently > have different perception of the risk level for the particular case of > internal delegation. > Anyway I will just cease in my intent and just act as it’s expected, > looking as guidance to the reaction of other CAs where possible. Again, I don’t disagree that it’s reasonable to see a difference between 1P and 3P if you’re a CA. But I look at the risk of “what attacks are now enabled if this is unaddressed”? Put differently, if a CA used a long-lived delegated responder, and I found out about it, I would absolutely be concerned and expect explanations. However, if the “worst” thing the delegated responder could do, if compromised, was “simply” sign OCSP responses, that’s at least better than the situation we’re in here. Because these delegated responders can, in many cases, cause new issuance, and because they are actively signing things other than OCSP responses (e.g. certificates), the threat model becomes unreasonably complex. The BRs have clear guidance on who absorbs the risk for a CA’s mistake: the CA and anyone who has obtained certificates from the CA. Historically, browsers have rather nobly stepped in and absorbed that risk for the ecosystem, introducing ever more complex solutions to try to allow site operators to continue with business as usual with minimal disruption. But that’s not what the “social contract” of a CA says should happen, and it’s not what the CP/CPS of the CA says will happen. It’s true that 4.9.1.2 “only” demands revocation, but any CA not treating this as recognizing the security impact and the similarity to a key misuse and/or compromise - even if “hypothetically” - does a disservice to all. I would just have a last request for you. I would appreciate if you can > express your views on Ben’s message about Mozilla’s position, in particular > about the 7-day deadline. > I think it’s of extreme benefit for all if the different browsers are > aligned. I participate here largely in an individual capacity, except as specified. I’ve already shared my risk analysis with Ben on that thread, but I also think it would be grossly negligent for a CA to try to look for “browser alignment” as a justification for ignoring the BRs, especially when so many platforms and libraries are put at risk by the CA’s misissuance. It sounds like you’re looking for an explicit “exception”, and while Ben’s message seems like a divergence from past Mozilla positions, I think it at least maintains consistency that “this is an incident, no exceptions”. Again, while wanting to ensure a safe space for questions, as a CA, your responsibility is to understand these issues and act accordingly. I wholly appreciate wanting to have an open and transparent discussion about the facts, and I am quite sensitive to the fact that there very well can be information being overlooked. As I said, and will say again: this is for your incident response to demonstrate, and as with any CA, and for any incident, you will be judged on how well and how timely you respond to the risks. Similarly, if you fail to revoke on time, how comprehensively you mitigate the lack of timeliness so that you can comprehensively demonstrate it will never happen again. Every time we encounter some non-compliance with an intermediate, CAs push back on their 4.9.1.2 obligations, saying it would be too disruptive. Heck, we’re still in a place where CAs are arguing even revoking the Subscriber cert under 4.9.1.1 is too disruptive, despite the CA claiming they would do so. This **has** to change, and so it needs to be clear that the first order is to expect a CA to **do what they said they would**, and revoke on the timetable defined. If there truly is an exceptional situation that prevents this, and the CA has a second incident for complying with the BRs for not revoking, then the only way that can or should not result in distrust of the CA is if their incident report can show that they understand the issue sufficiently and can commit to never delaying revocation again by showing comprehensively the step they are taking. There is little evidence that the majority of CAs are capable of this, but it’s literally been a Baseline Requirement since the start. For lack of a better analogy: it’s a borrower who is constantly asking for more and more credit to keep things going, and so they don’t default. If they default, you are unlikely to get your money back, but if you continue to loan them more and more, you’re just increasing your own risk for if/when they do default. The CA is the borrower, defaulting is being distrusted, browsers are the lenders, and the credit being extended is how flexible they are when misissuance events occur. Taking a delay on revocation for this issue is asking for a *huge* loan. For some CAs, that’s beyond the credit they
RE: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
GlobalSign recognizes the reported security issue and associated risk, and is working on a plan to remediate the impacted CA hierarchies with first priority on terminating those branches that include issuing CA with private keys outside of GlobalSign's realm. We will soon share an initial plan on our Bugzilla ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1649937. One question we have for the root store operators specifically is what type of assurance they are looking for on the key destruction activities. In the past we've both done key destruction ceremonies without and with (e.g. in the case of addressing a compliance issue like https://bugzilla.mozilla.org/show_bug.cgi?id=1591005) an external auditor witnessing the destruction and issuing an independent ISAE3000 witnessing report. > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: woensdag 1 juli 2020 23:06 > To: mozilla-dev-security-policy > Subject: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous > Delegated Responder Cert > > I've created a new batch of certificates that violate 4.9.9 of the BRs, which was > introduced with the first version of the Baseline Requirements as a MUST. This is > https://misissued.com/batch/138/ > > A quick inspection among the affected CAs include O fields of: QuoVadis, > GlobalSign, Digicert, HARICA, Certinomis, AS Sertifitseeimiskeskus, Actalis, > Atos, AC Camerfirma, SECOM, T-Systems, WISeKey, SCEE, and CNNIC. > > Section 4.9.9 of the BRs requires that OCSP Delegated Responders MUST > include an id-pkix-ocsp-nocheck extension. RFC 6960 defines an OCSP > Delegated Responder within Section 4.2.2.2 as indicated by the presence of the > id-kp-OCSPSigning as an EKU. > > These certificates lack the necessary extension, and as such, violate the BRs. As > the vast majority of these were issued on-or-after 2013-02-01, the Effective Date > of Mozilla Root CA Policy v2.1, these are misissued. You could also consider the > effective date as 2013-05-15, described later in [1] , without changing the results. > > This batch is NOT comprehensive. According to crt.sh, there are approximately > 293 certificates that meet the criteria of "issued by a Mozilla-trusted, TLS-capable > CA, with the OCSPSigning EKU, and without pkix-nocheck". misissued.com had > some issues with parsing some of these certificates, due to other non- > conformities, so I only included a sample. > > Censys.io is aware of approximately 276 certificates that meet this criteria, as you > can see at [2]. The differences in perspectives underscores the importance of > CAs needing to carefully examine the certificates they've issued to understand. > > It's important for CAs to understand this is Security Relevant. While they should > proceed with revoking these CAs within seven (7) days, as defined under the > Baseline Requirements Section 4.9.1.2, the degree of this issue likely also > justifies requiring witnessed Key Destruction Reports, in order to preserve the > integrity of the issuer of these certificates (which may include the CA's root). > > The reason for this is simple: In every case I examined, these are certificates that > appear to nominally be intended as Issuing CAs, not as OCSP Responder > Certificates. It would appear that many CAs were unfamiliar with RFC 6960 when > constructing their certificate profiles, and similarly ignored discussion of this issue > in the past [3], which highlighted the security impact of this. I've flagged this as a > SECURITY matter for CAs to carefully review, because in the cases where a > third-party, other than the Issuing CA, operates such a certificate, the Issuing CA > has delegated the ability to mint arbitrary OCSP responses to this third-party! > > For example, consider a certificate like https://crt.sh/?id=2657658699 . > This certificate, from HARICA, meets Mozilla's definition of "Technically > Constrained" for TLS, in that it lacks the id-kp-serverAuth EKU. However, > because it includes the OCSP Signing EKU, this certificate can be used to sign > arbitrary OCSP messages for HARICA's Root! > > This also applies to non-technically-constrained sub-CAs. For example, consider > this certificate https://crt.sh/?id=21606064 . It was issued by DigiCert to > Microsoft, granting Microsoft the ability to provide OCSP responses for any > certificate issued by Digicert's Baltimore CyberTrust Root. We know from > DigiCert's disclosures that this is independently operated by Microsoft. > > Unfortunately, revocation of this certificate is simply not enough to protect Mozilla > TLS users. This is because this Sub-CA COULD provide OCSP for itself that > would successfully validate, AND provide OCSP for other revoked sub-CAs, even > if it was revoked. That is, if this Sub-CA's key was maliciously used to sign a > GOOD response for itself, it would be accepted. > These security concerns are discussed in Section 4.2.2.2.1 of RFC
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On 03/07/2020 12:24, Ryan Sleevi via dev-security-policy wrote: The key destruction is the only way I can see being able to provide some assurance that “things won’t go wrong, because it’s impossible for them to go wrong, here’s the proof” Ryan, distrusting the root(s) would be another way to provide this assurance (for up-to-date clients anyway), although I'd be surprised if any of the affected CAs would prefer to go that route! -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Ryan, I don’t think I’m failing to see the security problem, but we evidently have different perception of the risk level for the particular case of internal delegation. Anyway I will just cease in my intent and just act as it’s expected, looking as guidance to the reaction of other CAs where possible. I would just have a last request for you. I would appreciate if you can express your views on Ben’s message about Mozilla’s position, in particular about the 7-day deadline. I think it’s of extreme benefit for all if the different browsers are aligned. Thanks, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Verifying Auditor Qualifications
On Fri, Jul 3, 2020 at 6:14 AM clemens.wanko--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > All, > on behalf of the Accredited Conformity Assessment Bodies council we would > like to provide the following background information to the guideline > “Verifying ETSI Auditor Qualification” as stated here: > > https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications > > The guideline explains the path for a formal verification of the > ETSI/eIDAS Auditor’s qualification through verification of corresponding > evidence. > The ACAB council is capable and happy to support this process in the > following way: > > o every CAB member of the council must be accredited according IEC/ISO > 17065 in conjunction with eIDAS Art. 3.18 and ETSI EN 319 403 or ETSI EN > 319 403-1 respectively. During the membership application and verification > process for the ACAB council, the applicant has to provide corresponding > evidence which are carefully checked. This is not what your charter says, nor what your website says. https://www.acab-c.com/app/download/5811554709/ACABc+Charter_V3.pdf https://www.acab-c.com/acab-c-members/ o ACAB’c members must incorporate and follow ETSI EN 319 403 for ETSI > audits. Especially for publicly trusted certificates, Part 2 of EN 319403 > must be followed which covers all additional requirements for Conformity > Assessment Bodies auditing Trust Service Providers that issue > Publicly-Trusted Certificates. In simple words, this means that it is > mandatory for the relevant Browser requirements incorporated by ETSI, to be > followed by an accredited CAB member of ACAB’c. This is not what your charter says. All this is considered and explicitly stated for the “Simplified check” > under 1. in the guideline: member CABs were checked following the “Standard > Check” which includes the ETSI EN 319 403 (…403-1/-2) referrer in the > accreditation documentation. The standard check is performed by ACAB’c as > described in the guideline and we certainly want to support the community > to rely on that. Hence, all CAB members of ACAB’C comply with the > accreditation requirements stated above. Where is the public evidence that this is true. I’m not disputing that this could be, and probably is, true. But there’s zero actual evidence for this that I can see, beyond your assurances here. And this is part of my abiding concern with the ETSI approach to audits, because we get grand assurances but when we actually look for them, they aren’t there. If we’re going to rely on ACAB’c, we need strong evidence of the claims here, not a well-intentioned post from an ACAB’c member. The task to verify that a conformity assessment body fulfils all normative > requirements, has necessary competences, etc. is performed by the National > Accreditation Bodies (NAB). Only if the CAB demonstrates their compliance > to the normative requirements (see above) they receive their accreditation > and/or can keep it upright. And time and time again, we’ve said that the NAB is *not* ensuring these requirements, because they aren’t as you described. The NAB ensures the requirements with respect to the notified scheme. Even if the CAB assessment is based on the ETSI assessment criteria for CABs, that still doesn’t provide any guarantee the CAB is using a scheme for assessing TSPs that is based on the ETSI criteria. The decision on the qualifications of an auditor is not done by ACAB’c but > the NAB which regularly checks the capabilities of the audit against the > requirements of EN 319 403. Citation Needed. But also, as I said above, 403 isn’t the relevant portion here. All that ACAB’c does is simplify the representation of accreditation by > bringing together information from the accreditation bodies. The full check > can always be made to confirm the information provided by ACAB’c. > > Standardisation for Trust Services (CA) under the European Scheme is > typically performed by the organizations ETSI or CEN or ISO/IEC. The ACAB > council is not a standardization organization. Yes, we know. I don’t understand why this was even included. It fits with my broader complaint against the ETSI ESI liaisons in the CABF: that every CABF, we get a recital of what ETSI is and isn’t and how NABs and CABs work, while the needs of the actual consumers go unmet and unaddressed. Look, as I said to Kathleen, I’m not unoppposed in spirit. But the statements you’ve made about what ACAB’c is, or what assurances it provides, are not backed up by what ACAB’c says and documents on its website. If the ACAB’c agrees that you’ve accurately represented things, it should be trivial to document these things within your charter. Unfortunately, for the many encouraging promises browsers have received from ACAB’c, there’s a worrying lack of substance or independent verification. The only statement supporting what you’ve claimed is as a footnote at https://www.acab-c.com that does not
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Hi Pedro, I’m not sure how best to proceed here. It seems like we’ve reached a point where you’re wanting to discuss possible ways to respond to this, as a CA, and it feels like this should be captured on the bug. I’m quite worried here, because this reply demonstrates that we’re at a point where there is still a rather large disconnect, and I’m not sure how to resolve it. It does not seem that there’s an understanding here of the security issues, and while I want to help as best I can, I also believe it’s appropriate that we accurately consider how well a CA understands security issue as part of considering incident response. I want there to be a safe space for questions, but I’m also deeply troubled by the confusion, and so I don’t know how to balance those two goals. On Fri, Jul 3, 2020 at 3:24 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > > Yes. But that doesn't mean we blindly trust the CA in doing so. And > that's > > the "security risk". > > But the point then is that a delegated responder that had the required > "noCheck" extension wouldn't be affected by this issue and CAs wouldn't > need to react, and therefore the issue to solve is the "mis-issuance" > itself due to the lack of the extension, not the fact that the CA > certificate could be used to do delegated responses for the same operator > of the Root, which is acceptable, as you said. I don’t understand why this is difficult to understand. If you have the noCheck extension, then as RFC 6960, you need to make that certificate short lived. The BRs require the cert have the extension. Similarly, if something goes wrong with such a responder, you also have to consider revoking the root, because it as-bad-as a root key compromise. In fact the side effect is that delegated responders operated externally > that have the required no check extension don't seem to be affected by the > issue and would be deemed acceptable, without requiring further action to > CAs, while the evident risk problem is still there. The “nocheck” discussion extension here is to highlight the compliance issue. The underlying issue is a security issue: things capable of providing OCSP responses that shouldn’t be. It seems you understand the security issue when viewing external sub-CAs: they can now impact the security of the issuer. It seems we’re at an impasse for understanding the issue for internally-operates Sub CAs: this breaks all of the auditable controls and assurance frameworks, and breaks the security goals of a “correctly” configured delegated responder, as discussed in the security considerations throughout RFC 6960. > > > > > I can understand that our views may differ: you may see 3P as "great > risk" > > and 1p as "acceptable risk". However, from the view of a browser or a > > relying party, "1p" and "3p" are the same: they're both CAs. So the risk > is > > the same, and the risk is unacceptable for both cases. > > But this is not actually like that, because what is required now to CAs is > to react appropriately to this incident, and you are imposing a unique > approach while the situations are fundamentally different. It's not the > same the derivations of this issue for CAs that had 3P delegation (or a mix > of 1P and 3P), and the ones, like us, that don't have such delegation. The burden is for your CA to establish that, in the incident response. I’ve seen nothing from you to reasonably establish that; you just say “but it’s different”. And that worries me, because it seems you don’t recognize that all of the controls and tools and expectations we have, both in terms of audits but also in all of the checks we make (for example, with crt.sh) *also* lose their credibility for as long as this exists. Again, I understand and appreciate the view that you seem to be advocating: “If nothing goes wrong, no one is harmed. If third-parties were involved, things could go wrong, so we understand that. But we won’t let anything go wrong ourselves.” But you seem to be misunderstanding what I’m saying: “If anything goes wrong, we will not be able to detect it, and all of our assumptions and safety features will fail. We could try and design new safety features, but now we’re having to literally pay for your mistake, which never should have happened in the first place.” That is a completely unfair and unreasonable thing for WISeKey to ask of the community: for everyone to change and adapt because WISeKey failed to follow the expectations. The key destruction is the only way I can see being able to provide some assurance that “things won’t go wrong, because it’s impossible for them to go wrong, here’s the proof” Anything short of that is asking the community to either accept the security risk that things can go wrong, or for everyone to go modify their code, including their tools to do things like check CT, to appropriately guard against that. Which is completely unreasonable. That’s how fundamental
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
For those who are interested, in contrast to the direct EKU validation with Test-Certificate, certutil does validate the OCSP signing EKU on the delegated OCSP signing certificate but doesn't validate the certificate chain for the OCSP signing EKU. Full test script and output can be found here: https://gist.github.com/vanbroup/84859cd10479ed95c64abe6fcdbdf83d On Thu, 2 Jul 2020 at 20:42, Paul van Brouwershaven < p...@vanbrouwershaven.com> wrote: > When validating the EKU using `Test-Certificate` Windows states it's > invalid, but when using `certutil` it's accepted or not explicitly checked. > https://gist.github.com/vanbroup/64760f1dba5894aa001b7222847f7eef > > When/if I have time I will try to do some further tests with a custom > setup to see if the EKU is validated at all. > > On Thu, 2 Jul 2020 at 19:26, Ryan Sleevi wrote: > >> >> >> On Thu, Jul 2, 2020 at 1:15 PM Paul van Brouwershaven < >> p...@vanbrouwershaven.com> wrote: >> >>> That's not correct, and is similar to the mistake I originally/previously made, and was thankfully corrected on, which also highlighted the security-relevant nature of it. I encourage you to give another pass at Robin's excellent write-up, at https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/XQd3rNF4yOo/bXYjt1mZAwAJ >>> >>> Thanks, it's an interesting thread, but as shown above, Windows does >>> validate the EKU chain, but doesn't look to validate it for delegated OCSP >>> signing certificates? >>> >> >> The problem is providing the EKU as you're doing, which forces chain >> validation of the EKU, as opposed to validating the OCSP response, which >> does not. >> >> A more appropriate test is to install the test root R as a locally >> trusted CA, issue an intermediate I (without the EKU/only >> id-kp-serverAuth), issue an OCSP responder O (with the EKU), and issue a >> leaf cert L. You can then validate the OCSP response from the responder >> cert (that is, an OCSP response signed by the chain O-I-R) for the >> certificate L-I-R. >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Verifying Auditor Qualifications
All, on behalf of the Accredited Conformity Assessment Bodies council we would like to provide the following background information to the guideline “Verifying ETSI Auditor Qualification” as stated here: https://wiki.mozilla.org/CA/Audit_Statements#Verifying_ETSI_Auditor_Qualifications The guideline explains the path for a formal verification of the ETSI/eIDAS Auditor’s qualification through verification of corresponding evidence. The ACAB council is capable and happy to support this process in the following way: o every CAB member of the council must be accredited according IEC/ISO 17065 in conjunction with eIDAS Art. 3.18 and ETSI EN 319 403 or ETSI EN 319 403-1 respectively. During the membership application and verification process for the ACAB council, the applicant has to provide corresponding evidence which are carefully checked. o ACAB’c members must incorporate and follow ETSI EN 319 403 for ETSI audits. Especially for publicly trusted certificates, Part 2 of EN 319403 must be followed which covers all additional requirements for Conformity Assessment Bodies auditing Trust Service Providers that issue Publicly-Trusted Certificates. In simple words, this means that it is mandatory for the relevant Browser requirements incorporated by ETSI, to be followed by an accredited CAB member of ACAB’c. All this is considered and explicitly stated for the “Simplified check” under 1. in the guideline: member CABs were checked following the “Standard Check” which includes the ETSI EN 319 403 (…403-1/-2) referrer in the accreditation documentation. The standard check is performed by ACAB’c as described in the guideline and we certainly want to support the community to rely on that. Hence, all CAB members of ACAB’C comply with the accreditation requirements stated above. The task to verify that a conformity assessment body fulfils all normative requirements, has necessary competences, etc. is performed by the National Accreditation Bodies (NAB). Only if the CAB demonstrates their compliance to the normative requirements (see above) they receive their accreditation and/or can keep it upright. The decision on the qualifications of an auditor is not done by ACAB’c but the NAB which regularly checks the capabilities of the audit against the requirements of EN 319 403. All that ACAB’c does is simplify the representation of accreditation by bringing together information from the accreditation bodies. The full check can always be made to confirm the information provided by ACAB’c. Standardisation for Trust Services (CA) under the European Scheme is typically performed by the organizations ETSI or CEN or ISO/IEC. The ACAB council is not a standardization organization. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
> > Yes. But that doesn't mean we blindly trust the CA in doing so. And that's > the "security risk". But the point then is that a delegated responder that had the required "noCheck" extension wouldn't be affected by this issue and CAs wouldn't need to react, and therefore the issue to solve is the "mis-issuance" itself due to the lack of the extension, not the fact that the CA certificate could be used to do delegated responses for the same operator of the Root, which is acceptable, as you said. In fact the side effect is that delegated responders operated externally that have the required no check extension don't seem to be affected by the issue and would be deemed acceptable, without requiring further action to CAs, while the evident risk problem is still there. > > I can understand that our views may differ: you may see 3P as "great risk" > and 1p as "acceptable risk". However, from the view of a browser or a > relying party, "1p" and "3p" are the same: they're both CAs. So the risk is > the same, and the risk is unacceptable for both cases. But this is not actually like that, because what is required now to CAs is to react appropriately to this incident, and you are imposing a unique approach while the situations are fundamentally different. It's not the same the derivations of this issue for CAs that had 3P delegation (or a mix of 1P and 3P), and the ones, like us, that don't have such delegation. In our particular case, where we have three affected CAs, owned and operated by WISeKey, we are proposing this action plan, for which we request feedback: 1.- Monday, new CAs will be created with new keys, that will be used to substitute the existing ones 2.- Monday, the existing CAs would be reissued with the same keys, removing the OCSP Signing EKU and with A REDUCED VALIDITY OF THREE MONTHS 3.- The existing CAs will be disabled for any new issuance, and will only be kept operative for signing CRLs and to attend revocation requests 4.- Within the 7 days period, the previous certificate of the CAs will be revoked, updating CCADB and OneCRL 5.- Once the re-issued certificates expire, we will destroy the keys and write the appropriate report In my humble opinion, this plan is: - Solving the BR compliance issue by revoking the offending certificate within the required period - Reducing even more the potential risk of hypothetical misuse of the keys by establishing a short life-time I hope this plan is acceptable. Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
