Re: Certinomis Issues
On Fri, May 10, 2019 at 09:59:48AM -0700, Wayne Thayer via dev-security-policy wrote: > > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > >> To continue to participate in the Mozilla CA program, I recommend that we > >> require Certinomis to create a new hierarchy and demonstrate their ability > >> to competently operate their CA by going through a new root inclusion > >> request. I’d like to propose two options for their existing root: > >> > >>1. Remove it from our root store in an upcoming Firefox release. > >>2. Constrain it to use for gouv.fr domains in an upcoming Firefox > >> release. [...] > If we decide to take option 2, I'm open to suggestions about the length of > time we should continue to trust the root for issuance to gouv.fr domains, > but I don't expect the answer to be "forever". One approach would be to > require a relatively quick transition prior to the inclusion of a new > Certinomis root. Another is to set a date far enough in the future that we > believe it would be reasonable for Certinomis to have a new root included > and transition to it, allowing gouv.fr site to continue to rely on > Certinomis. Apologies if I missed mention of this, but has there been any request from the operators of gouv.fr to maintain trust in Certinomis for subdomains thereof? I'd be *extremely* uncomfortable with the idea that Firefox would continue to trust an otherwise distrusted CA for a domain hierarchy without the enthusiastic and informed consent of the operator of that hierarchy. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Revocation Requirements for S/MIME Certificates
I've attempted to update section 6 to incorporate revocation requirements for S/MIME certificates: https://github.com/mozilla/pkipolicy/commit/15ad5b9180903b92b8f638c219740c0fb6ba0637 Note: since much of this language is copied directly from the BRs, if we decide to adopt it, the policy will also need to comply with the Creative Commons Attribution 4.0 International license used by the BRs. I will greatly appreciate everyone's review and comments on this proposed change. - Wayne On Mon, May 6, 2019 at 2:04 PM Jeremy Rowley wrote: > I think it should be added by Mozilla. The CAB Forum is a long way from > having an s/MIME policy in place (there's not even a working group yet). > Having no policy for cert revocation related to s/MIME ignores that s/MIME > are part of the Mozilla ecosystem and sequesters them from the rest of the > policy. Without a revocation policy, there's no requirement to revoke a > certificate mis-issued that's non-TLS. > > -Original Message- > From: dev-security-policy > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Friday, May 3, 2019 12:44 PM > To: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: Policy 2.7 Proposal: Clarify Revocation Requirements for > S/MIME Certificates > > Kathleen and Pedro, > > Thank you for raising these legitimate concerns. I continue to believe > that a literal reading of the current requirement is that it already does > apply to S/MIME certificates, and the discussion I mentioned supports that > interpretation. > > I propose two new options to solve this problem: > * Remove S/MIME certificates from the scope of section 6 and wait for the > CAB Forum to publish baseline requirements for S/MIME. I suspect that is a > few years away given that the working group is still in the process of > being chartered. However, this option is consistent with some people's > interpretation of the existing requirements. > * Add a subsection on revocation specific to S/MIME certificates and > populate it with a version of the BR requirements tailored to S/MIME. We'd > probably need to include requirements for S/MIME Intermediates as well as > leaf certificates. > > A third option would be to specify the parts of the BR revocation > requirements that don't apply to S/MIME certificates, but after reviewing > section 4.9.1, I think this would be confusing, at best. > > I would appreciate everyone's input on the best way to address this issue. > > - Wayne > > > On Fri, May 3, 2019 at 5:12 AM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hello, > > my main concern about applying this would be that this would lead to > > forbid the option to suspend a personal certificate. > > > > On a side note about suspension... I was not active in the forums when > > this was discussed and adopted and I'm sure there was a clear benefit > > on disallowing suspensions, but it's kind of a hassle already because > > of the application of this rule to the whole hierarchy. We'd like for > > example to have the capability to suspend a subordinate CA that is > > under investigation or that is pending of an audit, but right now we > > can't do it... extending these rules to personal certificates is not > > something I'm personally too enthusiastic. > > > > Best, > > Pedro > > > > El jueves, 2 de mayo de 2019, 17:32:43 (UTC+2), Kathleen Wilson > escribió: > > > Just want to make it very clear to everyone, that the proposal, to > > > add the following text to section 6 of Mozilla's Root Store Policy > > > would mean that certs constrained to id-kp-emailProtection > > > (end-entity and intermediate), i.e. S/MIME certs, would be subject > > > to the same BR rules and revocation timelines as TLS/SSL certs. > > > > > > > This requirement applies to certificates that are not otherwise > > required > > > >> to comply with the BRs. > > > > > > For example, Section 4.9.1.1 of the BRs says: > > > "" > > > MUST revoke a Certificate within 5 days if one or more of the > > > following > > > occurs: ... > > > > > > 1. The Certificate no longer complies with the requirements of > > > Sections > > > 6.1.5 and 6.1.6; > > > ... > > > 7. The CA is made aware that the Certificate was not issued in > > > accordance with these Requirements "" > > > > > > I interpret "these Requirements" to mean the BRs. Therefore, my > > > interpretation of the proposed additional text is that certs that > > > are constrained to S/MIME would also have to be issued in full > > > accordance with the BRs and would have to be revoked within the > > > timeline as specified in the BRs when found to be not in full > > > compliance with the BR issuance rules. > > > > > > Section 1.1 of Mozilla's root store policy limits the scope of the > > > policy such that the proposed additional text would only > > > specifically add the rules to S/MIME certs. Certs with no EKU > > > extension or anyExtendedKeyUsage are considered
Re: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
First off, I would like to remind everyone that participation in this forum
is subject to Mozilla's Community Participation Guidelines [1].
The arguments that have been made for adding an exception to our policy for
Policy CAs have not, in my opinion, made a clear and compelling case for
the exception. The only CA that has argued for this exception is the one
that proposed it. On the other hand, I do still believe that adding this
exception creates a significant new risk by introducing a poorly defined
term ("Policy CA") and by making enforcement more difficult. Unless
additional information is presented here, I do not plan to implement this
proposal.
- Wayne
[1] https://www.mozilla.org/en-US/about/governance/policies/participation/
On Thu, May 9, 2019 at 9:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 10/05/2019 05:25, Ryan Sleevi wrote:
> > On Thu, May 9, 2019 at 10:44 PM Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 09/05/2019 16:35, Ryan Sleevi wrote:
> >>> Given that the remark is that such a desire is common, perhaps you can
> >>> provide some external references documenting how one might go about
> >>> configuring such a set-up, particularly in the context of TLS trust?
> >>> Similarly, I'm not aware of any system that supports binding S/MIME
> >>> identities to a particularly CA (effectively, CA pinning) - perhaps you
> >> can
> >>> provide documentation and reference for systems that perform this?
> >>>
> >>> Thanks for helping me understand how this 'common' scenario is actually
> >>> implemented, especially given that the underlying codebases do not
> >> support
> >>> such distinctions.
> >>>
> >>
> >> My description is based on readily available information from the
> >> following sources, that you should also have access to:
> >>
> >
> > It looks like your links to external references may have gotten stripped,
> > as I didn't happen to receive any.
> >
> > As it relates to the topic at hand, the system you described is simply
> that
> > of internal CAs, and does not demonstrate a need to use publicly trusted
> > CAs. Further, going back to your previous message, to which I was
> replying
> > to make sure I did not misunderstand, given that you stated it was
> common,
> > it seemed we established that such scenarios in that message, and further
> > expanded upon in this, already have the capability for enterprise
> > management.
> >
> > I wanted to make sure I did my best to understand, so that we can have
> > productive engagement on substance, specifically around whether there is
> a
> > technical necessity for the use of non-Root CAs to be capable of issuance
> > under multiple different trust purposes. It does not seem as if there's
> > been any external references to establish a technical necessity, so it
> does
> > not seem like the policy needs to be modified, based on the available
> > evidence.
> >
>
> There were no links, only descriptions of obvious facts that you
> willfully ignore in an effort to troll the community.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> 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: Policy 2.7 Proposal: Exclude Policy Certification Authorities from EKU Requirement
On Mon, Apr 29, 2019 at 7:31 AM Peter Bowen wrote: > I support this, as long as Policy CAs meet the same operations standards > and have the same issuance restrictions as root CAs. This would result in > no real change to policy, as I assume roots not directly included in the > Mozilla root store were already considered “roots” for this part of the > policy. > > Section 5.3 already excludes "cross-certificates that share a private key with a corresponding root certificate" from the EKU requirement. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: CA Certificate Binding to Policy Documents
I have drafted the change as proposed, moving the exact "Required Practice" language into section 3.3 of the policy: https://github.com/mozilla/pkipolicy/commit/803ec1a1414318a69491854a867dc69889442b7b On Sat, Apr 27, 2019 at 11:36 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hello, > > I totally agree about the need to specify this information clearly in the > documentation framework, but I personally think that it's not always > adequate to force listing the intermediate CA certificates in the CP, but > definitely this information is required to be disclosed in the CPS. > > Pedro: I agree with you if there is only one CP. However when there are multiple CPs, there needs to be some way to determine which one applies to each CA certificate. Does the language I proposed give you enough flexibility to meet the requirement without forcing the listing of every intermediate in your CPs? My rational is that the Root CA in a Trust Model has the role to define > different CP for the different certificate profiles that are allowed in the > hierarchy, setting the rules to be implemented by the issuing CAs (this > includes the OIDs to include in the certificates to identify the associated > CP), and it's in the particular CPS published by a CA operating in the > Trust Model where it's specified the CPs implemented and by which Issuing > CAs. > > This is what we are intending now to do as part of the process to split > the ownership of the Roots and the Issuing CAs, in our particular case, so > we'd have: > - The Root Owner (OISTE Foundation) defines: >* A number of CP documents that define the practices to be implemented > while issuing a particular type of certificate. This includes things from > the allowed validation practices to the OIDs to be included in the > certificates to associate a leaf certificate with a CP > Can we determine which CP applies to a given intermediate based on OIDs? * its own CPS, that has as main scope the Root CAs, but also defines the > general practices of the whole Trust Model > - A subordinate CA operating under the Root, in our case it would WISeKey, > defines: >* A CPS which is defined in accordance of the OISTE CPS and that > discloses the practices implemented while issuing certificates of one or > more of the CP defined by OISTE. It's here where WISeKey includes the > information about the Issuing CAs implementing the different OISTE CP > > With this scenario, we consider that the CP document is not aware of the > particular CA that issues certificates of a particular kind, but this > information must be disclosed in the CA's CPS. > > I think it is okay if a CP isn't aware of a particular CA certificate, as long as there is some clear way to determine which CP applies to that intermediate. How does the CPS identify which CP applies to each intermediate? Our particular approach can be seen here: > - CP and CPS published by the OISTE Foundation: > https://oiste.org/repository/ > - CPS published by WISeKey (New version 3.0): > https://www.wisekey.com/repository/ > > So, this discussion is relevant to us, as it could imply that our approach > might need to be adapted. > > Best, > Pedro > > PS Please note that WISeKey as not fully adopted yet the new CP/CPS > documentation framework, as this has a dependency on Mozilla approving our > transfer request, as it's being discussed in > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hueaxNtUNl0 > > El sábado, 27 de abril de 2019, 0:15:00 (UTC+2), Wayne Thayer escribió: > > The required practice "Publicly Available CP and CPS" [1] states: > > > > The CP/CPS must clearly indicate which root and subordinate certificates > > > the practices and processes described in those documents apply to. > > > > > > This can be done in (at least) two ways: > > * the policy document can unambiguously list the specific CA certificates > > within its scope > > * the CA certificate can contain one or more policy OIDs that are > > referenced in the applicable policy documents > > > > I have found that many CP/CPSes don't clearly list the certificates that > > are in-scope, and the binding between policy OIDs in subordinate CA > > certificates and CP/CPSes is often unclear when the CA has multiple > policy > > documents. > > > > My concern is that this could lead to situations where a CA can pick and > > choose policies to argue that a given certificate is compliant. > > > > However, BR section 7.1.2.3 already requires each end-entity certificate > to > > include "A Policy Identifier, defined by the issuing CA, that indicates a > > Certificate Policy asserting the issuing CA's adherence to and compliance > > with these Requirements." I'm much more interested in compliance with the > > BRs and Mozilla policy than the CA's own CPS, so this mitigates my > concern. > > > > Even though I don't think this is as important now that I've given it > some > > thought, I propose moving the
Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs
Having received no comments on these proposed changes, I plan to include them in version 2.7 of our policy. - Wayne On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer wrote: > Ryan Sleevi made the following proposal: > > Issue #122 [1] previously discussed Section 8 in the context of >> subordinate CAs, with a change [2] being made to include subordinate CAs >> (in the context of Section 5.3.2) within scope of notification requirements. >> >> However, as presently worded, it's ambiguous as to whether or not >> Sections 8.1 through 8.3 also apply to subordinate CAs, or whether the only >> disclosure required is upon the initial introduction of the subordinate. >> This confusion results from language such as in Section 8.1, "or when an >> organization buys the private key of a certificate in Mozilla's root >> program", implying that private keys which transitively chain to a root >> certificate within Mozilla's program are exempt from such requirements. >> >> This ambiguity creates incentives for situations such as cross-signing >> CAs that might otherwise or have been otherwise rejected from direct >> inclusion within the Mozilla program. It further creates issues with >> respect to the supervision of audits and auditors. >> >> While it is true that the signing CA accepts the risk that an unfavorable >> verdict on the subordinate may impact the root, the cost of such a decision >> is primarily borne by Mozilla and the broader community, in that they are >> responsible for the collateral ecosystem challenges and devising >> appropriate solutions. This has been demonstrated, for example, through the >> discussion of Symantec issues [3]. >> >> Because Mozilla and the community bear significant cost, especially as >> more time passes and more certificates are issued, the following changes >> are suggested: >> >>1. Align Section 8, and its subsections, with language similar to >>that of Section 3.1.2.1. That is, that the policy is applicable to a CA >> and >>all subordinate CAs technically capable of issuing (server or e-mail) >>certificates >>2. With respect to Section 8.1, extend the requirements of the last >>paragraph to the issuance of subordinate CA certificates. Namely, if the >>private key is in possession of an entity that is new to the Mozilla root >>program, or subject to a CP or CPS that is new to the Mozilla Root >> Program, >>that prior to the issuance of such a certificate, there be a public >>discussion that results in a favorable conclusion. >> >> With the current policy as written, an existing/included root CA that >> plans to exit the CA business might be prohibited (by virtue of Section >> 8.1) from selling the business or (by virtue of Section 8.3) from >> transferring the private key material. However, they are fully permitted to >> cross-certify a new 'root' and then proverbially close up shop - with no >> consideration for if their root gets removed as a consequence. These are >> the same set of concerns that led to the introduction of Section 8, but >> today exist due to the ambiguity with respect to the subsections. >> > > I've proposed a fix for this issue: > https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8 > It also attempts to clarify the applicability of section 8.3 as "only" > when section 8.1 and/or section 8.2 also apply. > > This is https://github.com/mozilla/pkipolicy/issues/169 and > https://github.com/mozilla/pkipolicy/issues/140 > > I will greatly appreciate everyone's input on this topic. In particular, I > would like to hear from CAs that would be affected by the requirement for > any new subordinate CAs to go through a public discussion before issuing > certificates, with the outcome being positive or else the subordinate CA > certificate will be added to OneCRL (section 8.1). > > - Wayne > > [1] https://github.com/mozilla/pkipolicy/issues/122 > [2] > https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10 > [3] https://wiki.mozilla.org/CA:Symantec_Issues > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAA record checking issue
The difference is we actually have the data at time of issuance. It just wasn’t correctly relied on for these specific certs. I think this means there is an open question on whether the issuance even was a mis-issuance since the CAA information was collected…even if it wasn’t perfect. This is why we’re revising the approach to say “Were the certs actually mis-issued? If yes, revoke. If no, then don’t revoke.” I was looking at it like a law. You may think you trespassed by walking on some grass. But if permission was granted at the time to walk on the grass, then you never actually violated a rule (even if you didn’t know about the permission). If permission was granted later, you still broke that law and are accountable, even if no penalty is applied. Here, we didn’t appropriately store the information but the data may have been stored and checked in a process. More succinctly said, the difference is the broken process may result in compliantly issued certificates which is different than a broken certs that are then remediated. If I can prove the compliance at the time the cert was issued, then the certs shouldn’t be revoked. Does that makes sense? I can certainly revoke all 1100 if that’s the preferred approach, but I figure with a few days time I can better answer question of what were the results in a break of normally compliant process? Oh, one other factor is that the system wasn’t exploitable. The break was between two internal processes talking to each other so the errors couldn’t result in certificates issued to a bad actor. It was also a very low volume compared to normal issue. Neither of these are good reasons or excuses. Instead they are the reason we thought we should perhaps not revoke all the certs until we better understand the compliance implications. From: Ryan Sleevi Sent: Friday, May 10, 2019 2:16 PM To: Jeremy Rowley Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: The analysis was basically that all the verification documents are still good, which means if we issued the cert today, the issuance would pass without further checks (since the data itself is good for 825 days). Because of this, customers with domains that didn’t prohibit Digicert in their CAA record (anywhere in the chain) could simply reissue the certificate without a problem. We could require this of all customers. For the 16, issuance would fail if the CAA check was performed today. Therefore, we want to revoke those. The one reason I wanted more time to respond is that we think we may have most CAA records in our Splunk data for the time of issuance. Our new plan is that we will revoke all certs unless we can confirm the CAA record was permissive at the time of issuance. I don’t know the number of certs that we will revoke yet. I’ll post an update when we compare the Splunk data to the issuance data. Thanks for answering. I was hoping you had a more thorough analysis ;) I do have other questions about the implementation details, but I'll add those to the bug, so we can focus this discussion on the immediate remediation steps. I guess my reservation with such an approach (and this is more a metapoint) is consider issuing an EV certificate without having the supporting documentation and/or without validating the documentation. You later come back to the documents, validate them, and find out you got lucky - the information was actually correct, even though the controls failed and the process wasn't followed. Do you revoke the certificates, on the basis the process failed, or do you not revoke them, because they were eventually consistent? This might sound like a hypothetical, but it's a question this industry has faced in the past [1][2], and browsers have reached different conclusions than CAs. It's not immediately clear to me how the proposed response here differs from those past responses, and may highlight some of the difference in philosophies here. An analysis that considered these past events, and how they were received by the community, and how there may be different facts here that lead to different conclusions, would be useful in both validating and justifying the proposed course of action. The real problem was the CA would kick off a request to the CAA checker. If the CA encountered an error, the request would time out. The CAA record may still have checked the CAA records appropriately but the CA never pulled the information to verify issuance authorization. So it’s a mis-issuance unless we can pull the data and prove it wasn’t. Combing through the archive data will take a while. [1] https://wiki.mozilla.org/CA:Symantec_Issues#Issue_C:_Unauthorized_EV_Issuance_by_RAs_.28January_2014_-_February_2015.29 [2]
Re: CAA record checking issue
On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley wrote: > The analysis was basically that all the verification documents are still > good, which means if we issued the cert today, the issuance would pass > without further checks (since the data itself is good for 825 days). > Because of this, customers with domains that didn’t prohibit Digicert in > their CAA record (anywhere in the chain) could simply reissue the > certificate without a problem. We could require this of all customers. For > the 16, issuance would fail if the CAA check was performed today. > Therefore, we want to revoke those. > > > The one reason I wanted more time to respond is that we think we may have > most CAA records in our Splunk data for the time of issuance. Our new plan > is that we will revoke all certs unless we can confirm the CAA record was > permissive at the time of issuance. I don’t know the number of certs that > we will revoke yet. I’ll post an update when we compare the Splunk data to > the issuance data. > Thanks for answering. I was hoping you had a more thorough analysis ;) I do have other questions about the implementation details, but I'll add those to the bug, so we can focus this discussion on the immediate remediation steps. I guess my reservation with such an approach (and this is more a metapoint) is consider issuing an EV certificate without having the supporting documentation and/or without validating the documentation. You later come back to the documents, validate them, and find out you got lucky - the information was actually correct, even though the controls failed and the process wasn't followed. Do you revoke the certificates, on the basis the process failed, or do you not revoke them, because they were eventually consistent? This might sound like a hypothetical, but it's a question this industry has faced in the past [1][2], and browsers have reached different conclusions than CAs. It's not immediately clear to me how the proposed response here differs from those past responses, and may highlight some of the difference in philosophies here. An analysis that considered these past events, and how they were received by the community, and how there may be different facts here that lead to different conclusions, would be useful in both validating and justifying the proposed course of action. > The real problem was the CA would kick off a request to the CAA checker. > If the CA encountered an error, the request would time out. The CAA record > may still have checked the CAA records appropriately but the CA never > pulled the information to verify issuance authorization. So it’s a > mis-issuance unless we can pull the data and prove it wasn’t. Combing > through the archive data will take a while. > [1] https://wiki.mozilla.org/CA:Symantec_Issues#Issue_C:_Unauthorized_EV_Issuance_by_RAs_.28January_2014_-_February_2015.29 [2] https://wiki.mozilla.org/CA:Symantec_Issues#Issue_T:_CrossCert_Misissuances_.28January_2010_-_January_2017.29 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAA record checking issue
The analysis was basically that all the verification documents are still good, which means if we issued the cert today, the issuance would pass without further checks (since the data itself is good for 825 days). Because of this, customers with domains that didn’t prohibit Digicert in their CAA record (anywhere in the chain) could simply reissue the certificate without a problem. We could require this of all customers. For the 16, issuance would fail if the CAA check was performed today. Therefore, we want to revoke those. The one reason I wanted more time to respond is that we think we may have most CAA records in our Splunk data for the time of issuance. Our new plan is that we will revoke all certs unless we can confirm the CAA record was permissive at the time of issuance. I don’t know the number of certs that we will revoke yet. I’ll post an update when we compare the Splunk data to the issuance data. The real problem was the CA would kick off a request to the CAA checker. If the CA encountered an error, the request would time out. The CAA record may still have checked the CAA records appropriately but the CA never pulled the information to verify issuance authorization. So it’s a mis-issuance unless we can pull the data and prove it wasn’t. Combing through the archive data will take a while. Jeremy From: Ryan Sleevi Sent: Friday, May 10, 2019 11:54 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Could you share the risk analysis that helped you reach this latter conclusion? That is, CAA is a time of check thing, and, as you note, you can't be sure they were appropriately authorized at the time of issuance. Thus, even if the site operator is a DigiCert customer now, or might have disabled CAA now, there's no ability to determine whether or not they previously approved it - or even whether the holder of that old certificate is still the authorized domain representative now (e.g. in the event of a domain transfer or sale) In general, the default should be to revoke all. That said, if there's a thorough analysis that has considered this, and other scenarios, and that, on the whole, has led DigiCert to believe the current path is more appropriate, it'd be great if you could share that analysis. I think Tim's questions are useful as well, in understanding the reasoning. Basically, without stating a position on whether your analysis is right or wrong, I'm hoping you can show your work in detail, and all the factors you considered. That sort of analysis is what helps the community build confidence that the chosen path, despite being a violation of the BRs, is a reflection of a CA thoughtfully considering all perspectives. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: CAA record checking issue
Hey Tim, The issue was a call between the CA and CAA checker. The CAA checker would check the DNS and verify the DNSSEC chain. However, when retrieving the information from the CAA checker, the CA had the error, which means the CAA check was not evaluated correctly. Under normal operation the CAA check does the DNSSEC , CAA, and other DNS queries. Here it wasn't a DNS failure - it was a communication failure between the CA and CAA checker. I guess you could say there were two failures in this case. First that the CAA check timed out internally and second that the DNSSEC check never happened. The mis-issuance still amounts to the same thing. Normally, even if we get a DNS failure, we can usually check to see if the zone is signed (at least at the root zone). If there is a signed root zone, then we treat the entire zone as signed (meaning we fail on error). Jeremy -Original Message- From: Tim Shirley Sent: Friday, May 10, 2019 7:30 AM To: Jeremy Rowley ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue Jeremy, Thanks for sharing this. After reading your description, I'm curious how your system was previously (or is now) satisfying the third criteria needed to issue in the face of a record lookup failure: confirming that the domain's zone does not have a DNSSEC validation chain to the ICANN root. Wouldn't any issuance require at least one successful DNS query in order to confirm the lack of a DS record somewhere between the TLD and the domain you're checking so you know the domain doesn't have a valid DNSSEC chain? If the CAA checking service was down, wouldn't those have all timed out? Or are those checks being done from a different system that wasn't down? Regards, Tim On 5/9/19, 10:05 PM, "dev-security-policy on behalf of Jeremy Rowley via dev-security-policy" wrote: FYI, we posted this today: https://scanmail.trustwave.com/?c=4062=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw=5=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1550645 Basically we discovered an issue with our CAA record checking system. If the system timed out, we would treat the failure as a DNS failure instead of an internal failure. Per the BRs Section 3.2.2: "CAs are permitted to treat a record lookup failure as permission to issue if: . the failure is outside the CA's infrastructure; . the lookup has been retried at least once; and . the domain's zone does not have a DNSSEC validation chain to the ICANN root" The failure was not outside our infrastructure so issuance was improper. We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Other suggestions are welcome. The issue was put into the code back when CAA record checking became mandatory (Sept 2017). We generally have a peer review of our code so that at least one other developer has looked at the system before release. In this case, neither PM nor a second reviewer was involved in the development. We've since implemented more stringent development processes, including ensuring a PM reviews and brings questions about projects to the compliance team. Anyway, let me know what questions, comments, etc you have. Thanks! Jeremy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA record checking issue
Okay. I'm working on something and will post it soon. From: Ryan Sleevi Sent: Friday, May 10, 2019 11:54:14 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Could you share the risk analysis that helped you reach this latter conclusion? That is, CAA is a time of check thing, and, as you note, you can't be sure they were appropriately authorized at the time of issuance. Thus, even if the site operator is a DigiCert customer now, or might have disabled CAA now, there's no ability to determine whether or not they previously approved it - or even whether the holder of that old certificate is still the authorized domain representative now (e.g. in the event of a domain transfer or sale) In general, the default should be to revoke all. That said, if there's a thorough analysis that has considered this, and other scenarios, and that, on the whole, has led DigiCert to believe the current path is more appropriate, it'd be great if you could share that analysis. I think Tim's questions are useful as well, in understanding the reasoning. Basically, without stating a position on whether your analysis is right or wrong, I'm hoping you can show your work in detail, and all the factors you considered. That sort of analysis is what helps the community build confidence that the chosen path, despite being a violation of the BRs, is a reflection of a CA thoughtfully considering all perspectives. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA record checking issue
On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > We checked all the applicable CAA records and found 16 where the CAA record > would not permit us to issue if we were issuing a new cert today. What we > are proposing is to revoke these certificates and reissue them (if they > pass > all the proper checks). The rest would pass if we issued today so we were > going to leave these where they are while disclosing them to the Mozilla > community. > Could you share the risk analysis that helped you reach this latter conclusion? That is, CAA is a time of check thing, and, as you note, you can't be sure they were appropriately authorized at the time of issuance. Thus, even if the site operator is a DigiCert customer now, or might have disabled CAA now, there's no ability to determine whether or not they previously approved it - or even whether the holder of that old certificate is still the authorized domain representative now (e.g. in the event of a domain transfer or sale) In general, the default should be to revoke all. That said, if there's a thorough analysis that has considered this, and other scenarios, and that, on the whole, has led DigiCert to believe the current path is more appropriate, it'd be great if you could share that analysis. I think Tim's questions are useful as well, in understanding the reasoning. Basically, without stating a position on whether your analysis is right or wrong, I'm hoping you can show your work in detail, and all the factors you considered. That sort of analysis is what helps the community build confidence that the chosen path, despite being a violation of the BRs, is a reflection of a CA thoughtfully considering all perspectives. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
On Wed, May 8, 2019 at 10:32 AM Ryan Sleevi wrote: > > On Tue, May 7, 2019 at 7:48 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> To continue to participate in the Mozilla CA program, I recommend that we >> require Certinomis to create a new hierarchy and demonstrate their ability >> to competently operate their CA by going through a new root inclusion >> request. I’d like to propose two options for their existing root: >> >>1. Remove it from our root store in an upcoming Firefox release. >>2. Constrain it to use for gouv.fr domains in an upcoming Firefox >> release. >> >> While there are only a few thousand unexpired TLS certificates (the root >> is >> not trusted for email) known to chain to this root, a few are in use by >> major French government websites (e.g. ants.gouv.fr). I have suggested >> option #2 to minimize disruption to those subscribers and relying parties. >> >> I will greatly appreciate everyone’s input on my recommendation and the >> proposed options. >> > > Thanks Wayne for ensuring the conversation progresses in a timely fashion. > > Your Option #2 does have precedent, both by Mozilla and by other browser > vendors, so I can understand the appeal. Some of these incidents have been > documented by Mozilla [1] in the context of past discussions about > voluntary name constraints [2], which captured a lengthy discussion about > some of the tradeoffs involved. > > I appreciate that your Option #2 is only proposed in the context of > addressing compatibility risks. Other CA events have prompted similar > analysis, with different vendors taking different approaches (e.g. [3] vs > [4]/[5], [6] v [7]). Despite these initial differences, it's worth noting > that even in these cases of addressing potential compatibility issues, the > industry uniformly aligned on ultimately removing trust in these CAs. It is > unclear whether your Option #2 is proposing such a convergence, and when, > or whether you see this as an indefinite proposition. > > If we decide to take option 2, I'm open to suggestions about the length of time we should continue to trust the root for issuance to gouv.fr domains, but I don't expect the answer to be "forever". One approach would be to require a relatively quick transition prior to the inclusion of a new Certinomis root. Another is to set a date far enough in the future that we believe it would be reasonable for Certinomis to have a new root included and transition to it, allowing gouv.fr site to continue to rely on Certinomis. One thing to consider with the creation of allowlists, whether in the > context of name constraints (e.g. India CCA, ANSSI) or in the context of > specific domains and certificates (Apple and Google, respectively, in the > context of WoSign/StartCom), an important factor to consider is not just > the compatibility, but the risk and value of the domain(s) being protected. > If the conclusion is that Certinomis' existing controls are insufficient to > provide reliable security, and its operations are not robust enough to > provide the assurances that the community and Mozilla users critically > depend on, then it seems important to also consider the potential harm of > misissued certificates for those domains > > In the case of India CCA, this was part of the Indian National Informatics > Center (India NIC), which itself was the domain registry for these domains. > Similarly, while AFNIC is the operator for the French TLDs, ANSSI was the > French national computer security agency to protect government systems. In > these cases, the allowlist effectively and specifically accomodated the > government needs and oversight. In the case of Certinomis, it is unclear > whether the French Government itself would want to delegate the control and > protection of its critical systems to an organization that has suffered > such repeated failures. > > Has there been any communication with the agencies tasked with this - most > likely, ANSSI itself? For example, the same concerns that lead to > contemplating "Option #1" may similarly lead the French government to > replace their certificates, rather than run further risk of misissuance. > Similarly, has there been any consideration to simply allowlist the limited > existing certificates, with a clear sunset date, as an alternative to name > constraining? > > No, I have not attempted to contact these site operators, nor has the option of allowlisting specific certificates been given any consideration. I am not opposed to the idea of allowlisting specific certificates. My overarching concern with any solution that does not eventually coverge > at #1, if not begin there, is that it creates significant confusion about > to what extent "legacy compatibility" is valued compared to "security". If > such compatibility, with such a small number of sites, is such a concern, > then as Jonathan Rudenberg has highlighted, it's useful to consider what > other,
Re: Certinomis Issues
On Fri, May 10, 2019 at 8:09 AM fchassery--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear Wayne, > > I’m not arguing that signing the new Startom root was a mistake.In fact, > as soon as we were told, we backed off. > Our understanding at that time was that the remediation plan had been > fully implemented. But the Mozilla staff did not agree and had another > interpretation of the situation. > I do not know how or when a distortion was introduced between Franck’s > exchange with the Mozilla staff and our action. > But there was no intent to circumvent the Mozilla plan, and we corrected > it immediately when we were asked to do so. > That is why I do not understand why this subject is included in the > present discussions: if there has been an error, it is a past error, > corrected in the past and on which no further action is possible. > The answer can be found on our Maintenance and Enforcement wiki page under the Recurring Issues section [1], which states (in part) "Mozilla considers the totality of known issues and patterns of behavior in a CA's response to those issues." [1] https://wiki.mozilla.org/CA/Maintenance_and_Enforcement#Recurring_Issues At a minimum it should only be recalled as a problem that has been solved. > > Kind Regards, > > François > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
Le vendredi 10 mai 2019 06:37:11 UTC+2, Wayne Thayer a écrit : > On Thu, May 9, 2019 at 8:56 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 10/05/2019 02:22, Wayne Thayer wrote: > > > Thank you for this response Francois. I have added it to the issues list > > > [1]. Because the response is not structures the same as the issues list, > > I > > > did not attempt to associate parts of the response with specific issues. > > I > > > added the complete response to the bottom of the page. > > > > > > On Thu, May 9, 2019 at 9:27 AM fchassery--- via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > >> ... > > > ... > > > > > > In response to the email from Franck that you mention, Gerv responded [1] > > > by quoting the plan he had approved and stating "This seems to be very > > > different to the plan you implemented." By cross-signing Startcom's old > > > roots, Certinomis did assist Startcom in circumventing the remediation > > > plan, and by proposing one plan then implementing a different one, > > > Certinomis did so without Mozilla's consent. > > > > > > > As can be seen from your [3] link, Certinomis cross-signed StartCom's > > NEW supposedly remediated 2017 hierarchy, not the old root. > > > > Thank you for correcting me Jakob. I was confused by a statement in the > 2017 thread that I referenced, but I see now that Certinomis only > cross-signed Startcom's new roots. Since Certinomis cross-signed Startcom's > new roots before the remediation plan was completed, I believe the > statements I made are otherwise correct. Dear Wayne, I’m not arguing that signing the new Startom root was a mistake.In fact, as soon as we were told, we backed off. Our understanding at that time was that the remediation plan had been fully implemented. But the Mozilla staff did not agree and had another interpretation of the situation. I do not know how or when a distortion was introduced between Franck’s exchange with the Mozilla staff and our action. But there was no intent to circumvent the Mozilla plan, and we corrected it immediately when we were asked to do so. That is why I do not understand why this subject is included in the present discussions: if there has been an error, it is a past error, corrected in the past and on which no further action is possible. At a minimum it should only be recalled as a problem that has been solved. Kind Regards, François ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAA record checking issue
Jeremy, Thanks for sharing this. After reading your description, I'm curious how your system was previously (or is now) satisfying the third criteria needed to issue in the face of a record lookup failure: confirming that the domain's zone does not have a DNSSEC validation chain to the ICANN root. Wouldn't any issuance require at least one successful DNS query in order to confirm the lack of a DS record somewhere between the TLD and the domain you're checking so you know the domain doesn't have a valid DNSSEC chain? If the CAA checking service was down, wouldn't those have all timed out? Or are those checks being done from a different system that wasn't down? Regards, Tim On 5/9/19, 10:05 PM, "dev-security-policy on behalf of Jeremy Rowley via dev-security-policy" wrote: FYI, we posted this today: https://scanmail.trustwave.com/?c=4062=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw=5=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1550645 Basically we discovered an issue with our CAA record checking system. If the system timed out, we would treat the failure as a DNS failure instead of an internal failure. Per the BRs Section 3.2.2: "CAs are permitted to treat a record lookup failure as permission to issue if: . the failure is outside the CA's infrastructure; . the lookup has been retried at least once; and . the domain's zone does not have a DNSSEC validation chain to the ICANN root" The failure was not outside our infrastructure so issuance was improper. We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Other suggestions are welcome. The issue was put into the code back when CAA record checking became mandatory (Sept 2017). We generally have a peer review of our code so that at least one other developer has looked at the system before release. In this case, neither PM nor a second reviewer was involved in the development. We've since implemented more stringent development processes, including ensuring a PM reviews and brings questions about projects to the compliance team. Anyway, let me know what questions, comments, etc you have. Thanks! Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
