Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs
Adding to Jeremy's post, I believe we need to also define a normative requirement to mark an unconstrained Intermediate CA Certificate not operated by the entity that controls the Root Key. Section 7.1.6.3 of the Baseline Requirements requires an explicit policy identifier for these subCAs. The anyPolicy identifier is not permitted. So, I assume that all Intermediate CA Certificates that include the anyPolicy identifier should be operated by the Issuing CA (or an Affiliate). Unfortunately -in one sense-, the BRs allow more specific policy identifiers even for Intermediate CA Certificates that ARE operated by the Issuing CA, so it is hard to differentiate which subCA is "Internal" or "External". I believe this is serious enough to consider the possibility of requiring a specific policy identifier (assigned by the CABF) to be included in externally-operated subCA Certificates, in addition to any other policy identifiers that the Issuing CA has chosen for that CA Certificate. Of course, other solutions might be available. Mozilla is also going over a close investigation of unconstrained subCAs that are missing audits and possibly included in oneCRL. I don't believe these subCAs should be grandfathered in. However, others that have supplied audit reports, following Mozilla Policies and indicating compliance with the BRs, should be grandfathered. Dimitris. On 2019-10-04 3:06 π.μ., Jeremy Rowley via dev-security-policy wrote: Hey Wayne, I think there might be confusion on how the notification is supposed to happen. Is notification through CCADB sufficient? We've uploaded all of the Sub CAs to CCADB including the technically constrained ICAs. Each one that is hosted/operated by itself is marked that way using the Subordinate CA Owner field. Section 8 links to emailing certifica...@mozilla.org but operationally, CCADB has become the default means of providing this notice. If you're expecting email, that may be worth clarifying in case CAs missed that an email is required. I know I missed that, and because CCADB is the common method of notification there is a chance that notice was considered sent but not in the expected way. There's also confusion over the "new to Mozilla" language I think. I interpreted this language as organizations issued cross-signs after the policy. For example, Siemens operated a Sub CA through Quovadis prior to policy date so they aren't "new" to the CA space even if they were re-certified. However, they would be new in the sense you identified - they haven't gone through an extensive review by the community. If the goal is to ensure the community review happens for each Sub CA, then requiring all recertifications to go through an approval process makes sense instead of making an exception for new. I'm not sure how many exist currently, but if there are not that many organizations, does a grandfathering clause cause unnecessary complexity? I realize this is not in DigiCert's best interest, but the community may benefit the most by simply requiring a review of all Sub CAs instead of trying to grandfather in existing cross-signs. Do you have an idea on the number that might entail ? At worst, we waste a bunch of time discovering that all of these are perfectly operated and that they could have been grandfathered in the first place. At best, we identify some critical issues and resolve them as a community. If there are a significant number of unconstrained on-prem CAs, then language that requires a review on re-signing would be helpful. Perhaps say "As of X date, a CA MUST NOT sign a non-technically constrained certificate where cA=True for keys that are hosted external to the CA's infrastructure or that are not operated in accordance with the issuing CA's policies and procedures unless Mozilla has first granted permission for such certificate"? The wording needs work of course, but the idea is that they go through the discussion and Mozilla signs off. A process for unconstrained Sub CAs that is substantially similar to the root inclusion makes sense, but there is documentation on CCADB for the existing ones. Still, this documentation should probably made available, along with the previous incident reports, to the community for review and discussion. Afterall, anything not fully constrained is essentially operating the same as a fully embedded root. Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a bad idea, and I fully support more careful scrutiny on which entities are controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are responsible for over half of the incident reports, with issues ranging from missed audit dates to incorrect profile information. The long cycle in getting information, being a middle-man information gathering, and trying to convey both Mozilla and CAB forum policy makes controlling compliance very difficult, and a practice I would not recommend to any
Re: Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI
On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy wrote: > > On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote: > > [snip] > > > I guess I wasn't specific enough. I am looking for a good study that > > > supports the proposition that the Internet community has (1) made a > > > concerted effort to ensure that there is only one authentic domain per > > > entity (or, at most, per entity-service, e.g, retail brokerage > > > services); and (2) has made a concerted effort to educate users to use > > > only that domain; and (3) that those steps have failed to significantly > > > reduce the successful phishing rate of the users that steps (1) and (2) > > > targeted. > > > > > > > > > Was it intentional to presume that (1) is correct or desirable? It’s > > > unclear if you believe it is, but if it isn’t (and for many reasons, it > > > isn’t), then naturally one might assume (2) and (3) don’t exist. > > Yes, I do believe that (1) is desirable. It has a long history in the > context of brand identity (e.g., "Coke" in red and white script), where > virtually all consumers use it to identify authentic products and reject > counterfeits. This is a valuable analogy, but I'm not sure how it advances the argument you appear to be making. To take the specific example you've provided, there is more than one product made under the general brand of "Coke", most -- but not all -- involving the word "Coke" in way or another. If we take the "domain name per product" analogy, there would be a bunch of different "domains" for these products: coke, newcoke, cocacolaclassic, dietcoke, cokezero, vanillacoke, caffeinefreecoke, and so on. That's before we start considering other products produced and marketed by the same company under different names. There's a bunch of other carbonated beverages, plus uncarbonated beverages, and even non-beverage foodstuffs, that are all produced and/or marketed by the company that produces and markets "Coke", at least in the country I'm from. Contrariwise, neither the word "Coke", nor white writing on a red background, nor even the specific font used, unambiguously identify one particular brand -- and even then, it is only in the context of beverages (attempts by trademark-maximalists notwithstanding). Further, as the rather extensive examples of counterfeit goods demonstrate, the mere existence of a trademark, or even active measures, does not stop counterfeiting, nor does it even attempt to -- it only tries to make counterfeiting commercially unattractive. Where the analogy breaks down is that in the case of phishing, people don't typically try to "counterfeit" the domain name, merely "confuse". If I make a product called "Matt's Coke" and sell it, I may certainly find myself in some legal hot water, but it won't be because of "counterfeiting", but rather a more nebulous form of trademark infringement around confusion. > Basically, many internet-based entities appear to have brought phishing upon > themselves by failing to extend the above to their internet presences. > Instead, they've trained their users to accept as authentic any domain that > has a passing resemblance to their rat's-nest of legitimate domains. While there's a certain amount of truth to that, I think quite a lot of it is users just not checking *anything* about the link they're clicking. The amount of spam I get inviting me to login to various banking websites using a link to yevgeniysflowershoppe.ua or the like would suggest that phishing doesn't not absolutely rely on confusion. Your hypothesis relies on the idea that users can be trained in any meaningful fashion, which the research seems to not support at all. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI
On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote: [snip] I guess I wasn't specific enough. I am looking for a good study that supports the proposition that the Internet community has (1) made a concerted effort to ensure that there is only one authentic domain per entity (or, at most, per entity-service, e.g, retail brokerage services); and (2) has made a concerted effort to educate users to use only that domain; and (3) that those steps have failed to significantly reduce the successful phishing rate of the users that steps (1) and (2) targeted. Was it intentional to presume that (1) is correct or desirable? It’s unclear if you believe it is, but if it isn’t (and for many reasons, it isn’t), then naturally one might assume (2) and (3) don’t exist. Yes, I do believe that (1) is desirable. It has a long history in the context of brand identity (e.g., "Coke" in red and white script), where virtually all consumers use it to identify authentic products and reject counterfeits. Entities also vigorously promote and protect their brand identities via trademarks and related litigation, and authorities even sometimes investigate and prosecute counterfeiters. Basically, many internet-based entities appear to have brought phishing upon themselves by failing to extend the above to their internet presences. Instead, they've trained their users to accept as authentic any domain that has a passing resemblance to their rat's-nest of legitimate domains. -R ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs
Hey Wayne, I think there might be confusion on how the notification is supposed to happen. Is notification through CCADB sufficient? We've uploaded all of the Sub CAs to CCADB including the technically constrained ICAs. Each one that is hosted/operated by itself is marked that way using the Subordinate CA Owner field. Section 8 links to emailing certifica...@mozilla.org but operationally, CCADB has become the default means of providing this notice. If you're expecting email, that may be worth clarifying in case CAs missed that an email is required. I know I missed that, and because CCADB is the common method of notification there is a chance that notice was considered sent but not in the expected way. There's also confusion over the "new to Mozilla" language I think. I interpreted this language as organizations issued cross-signs after the policy. For example, Siemens operated a Sub CA through Quovadis prior to policy date so they aren't "new" to the CA space even if they were re-certified. However, they would be new in the sense you identified - they haven't gone through an extensive review by the community. If the goal is to ensure the community review happens for each Sub CA, then requiring all recertifications to go through an approval process makes sense instead of making an exception for new. I'm not sure how many exist currently, but if there are not that many organizations, does a grandfathering clause cause unnecessary complexity? I realize this is not in DigiCert's best interest, but the community may benefit the most by simply requiring a review of all Sub CAs instead of trying to grandfather in existing cross-signs. Do you have an idea on the number that might entail ? At worst, we waste a bunch of time discovering that all of these are perfectly operated and that they could have been grandfathered in the first place. At best, we identify some critical issues and resolve them as a community. If there are a significant number of unconstrained on-prem CAs, then language that requires a review on re-signing would be helpful. Perhaps say "As of X date, a CA MUST NOT sign a non-technically constrained certificate where cA=True for keys that are hosted external to the CA's infrastructure or that are not operated in accordance with the issuing CA's policies and procedures unless Mozilla has first granted permission for such certificate"? The wording needs work of course, but the idea is that they go through the discussion and Mozilla signs off. A process for unconstrained Sub CAs that is substantially similar to the root inclusion makes sense, but there is documentation on CCADB for the existing ones. Still, this documentation should probably made available, along with the previous incident reports, to the community for review and discussion. Afterall, anything not fully constrained is essentially operating the same as a fully embedded root. Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a bad idea, and I fully support more careful scrutiny on which entities are controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are responsible for over half of the incident reports, with issues ranging from missed audit dates to incorrect profile information. The long cycle in getting information, being a middle-man information gathering, and trying to convey both Mozilla and CAB forum policy makes controlling compliance very difficult, and a practice I would not recommend to any CA. Once you've established a relationship as a signer CA (or acquired a relationship), extraditing yourself is... difficult. The certificates end up embedded on smart cards, used by government institutions and pinned in weird places. And the unfortunate part is you don't have the direct relationship with the end-user to offer counsel against some of the practices. That extra abstraction layer between the CA and root store program ends up adding a lot more complexity than you'd initially think. Delegating the CA responsibility ends up being a bad idea and takes years to fix. DigiCert is finally down to the final few TLS sub CAs (5) and each are operating in OCSP signing mode only. They'll all be revoked in 2020. Jeremy -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Thursday, October 3, 2019 2:45 PM To: mozilla-dev-security-policy Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs I'd like to revisit this topic because I see it as a significant change and am surprised that it didn't generate any discussion. Taking a step back, a change [1] to notification requirements was made last year to require CAs that are signing unconstrained subordinate CAs (including cross-certs) controlled by a different organization to notify Mozilla. We have received few, if any, notifications of this nature, so I have to wonder if CAs are adhering to
Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI
On Thu, Oct 3, 2019 at 3:45 PM Ronald Crane via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 10/2/2019 9:44 PM, Peter Gutmann via dev-security-policy wrote: > > Ronald Crane via dev-security-policy < > dev-security-policy@lists.mozilla.org> writes: > > > >> Please cite the best study you know about on this topic (BTW, I am > *not* snidely > >> implying that there isn't one). > > Sure, gimme a day or two since I'm away at the moment. > > > > Alternatively, there's been such a vast amount of work done on this that > a few > > seconds of googling should find plenty of publications. As the first > search > > text that came to mind, "browser ui phishing" returns just under half a > million > > hits. Making it "browser ui phishing inurl:.pdf" to get just papers > (rather than > > web articles, blog posts, etc) reduces that to 30,000 results. > > I guess I wasn't specific enough. I am looking for a good study that > supports the proposition that the Internet community has (1) made a > concerted effort to ensure that there is only one authentic domain per > entity (or, at most, per entity-service, e.g, retail brokerage > services); and (2) has made a concerted effort to educate users to use > only that domain; and (3) that those steps have failed to significantly > reduce the successful phishing rate of the users that steps (1) and (2) > targeted. Was it intentional to presume that (1) is correct or desirable? It’s unclear if you believe it is, but if it isn’t (and for many reasons, it isn’t), then naturally one might assume (2) and (3) don’t exist. > > -R > > > ___ > 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:Extend Section 8 to Encompass Subordinate CAs
I'd like to revisit this topic because I see it as a significant change and am surprised that it didn't generate any discussion. Taking a step back, a change [1] to notification requirements was made last year to require CAs that are signing unconstrained subordinate CAs (including cross-certs) controlled by a different organization to notify Mozilla. We have received few, if any, notifications of this nature, so I have to wonder if CAs are adhering to this requirement. This requirement applies as follows: an organization other than the CA obtains control of an unconstrained > intermediate certificate (as defined in section 5.3.2 of this policy) that > directly or transitively chains to the CA's included certificate(s); > Is the "obtains control" language being interpreted to mean that this only applies when control of the private keys change, and not when a CA signs a key controlled by a different organization? I believe the intent is for this to apply in both situations - otherwise it is trivial to bypass. The new change [2] proposed for version 2.7 of our policy goes one step further and places transfers and signings of unconstrained subordinate CAs clearly in the scope of section 8.1, including the following language: If the receiving or acquiring company is new to the Mozilla root program, > it must demonstrate compliance with the entirety of this policy and there > MUST be a public discussion regarding their admittance to the root program, > which Mozilla must resolve with a positive conclusion in order for the > affected certificate(s) to remain in the root program. If the entire CA > operation is not included in the scope of the transaction, issuance is not > permitted until the discussion has been resolved with a positive conclusion. That means any organization "new to the Mozilla root program" for which a CA signs an unconstrained subordinate CA or cross-cert must go through an approval process including a public discussion before issuing certificates in order to comply with this policy. It also means that we need to decide what "new to the Mozilla root program" means. Organizations that control unconstrained subordinate CAs have not been considered members of the program in the past, so it's easy to argue that every such organization will be "new to the Mozilla root program" if/when this policy goes into effect. However, it may be more practical to "grandfather in" organizations that are currently in control of unconstrained subordinate CAs. This also raises the question of what it means to "demonstrate compliance with the entirety of this policy". Section 8.1 has historically applied to companies acquiring root CAs and we have not required them to go through the entire inclusion process - only a public discussion. Should that same interpretation apply to unconstrained subordinate CA? Before proposing any changes, I'd like to ask for everyone's input on these and any other concerns stemming from this policy proposal. - Wayne [1] https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10 [2] https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8 On Fri, May 10, 2019 at 1:58 PM Wayne Thayer wrote: > 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,
Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI
On 10/2/2019 9:44 PM, Peter Gutmann via dev-security-policy wrote: Ronald Crane via dev-security-policy writes: Please cite the best study you know about on this topic (BTW, I am *not* snidely implying that there isn't one). Sure, gimme a day or two since I'm away at the moment. Alternatively, there's been such a vast amount of work done on this that a few seconds of googling should find plenty of publications. As the first search text that came to mind, "browser ui phishing" returns just under half a million hits. Making it "browser ui phishing inurl:.pdf" to get just papers (rather than web articles, blog posts, etc) reduces that to 30,000 results. I guess I wasn't specific enough. I am looking for a good study that supports the proposition that the Internet community has (1) made a concerted effort to ensure that there is only one authentic domain per entity (or, at most, per entity-service, e.g, retail brokerage services); and (2) has made a concerted effort to educate users to use only that domain; and (3) that those steps have failed to significantly reduce the successful phishing rate of the users that steps (1) and (2) targeted. -R ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert OCSP services returns 1 byte
I've gone ahead and moved [4] to the "Recommended Practices" section. The ballot to modify the BRs is now in the formal discussion period leading up to a vote [5]. I'll be resolving the existing compliance bugs on this issue as INVALID. I'd like to thank the CAs that proactively submitted incident reports rather than taking a "wait and see" approach. That degree of transparency is both appreciated and encouraged. - Wayne [5] https://cabforum.org/pipermail/servercert-wg/2019-October/001145.html On Wed, Oct 2, 2019 at 2:20 AM Rob Stradling wrote: > On 02/10/2019 00:51, Wayne Thayer wrote: > > On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote: > > > > I propose that you update [4] to say that Mozilla won't treat > > non-compliance with [4] as an "incident" whilst it remains the case > > that the BRs are inconsistent with [4]. > > > > I could simply move [4] to a "recommended practice" (SHOULD) until the > > ballot comes into force, then move it back to "required". That implies > > that the bugs which have been opened for this specific issue (responding > > "unknown" - not to be confused with "returns 1 byte") will be closed as > > INVALID. > > > > Are there strong objections to this course of action? > > It seems a bit strange to recommend a practice that CAs cannot currently > adhere to without violating the BRs and some other root programs' > policies, but at the same time it is helpful to signpost upcoming policy > changes. > > I don't object strongly. > > > - Wayne > > > > [4] > > > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates > > -- > 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
