Based on this discussion, I propose adding the following statement to the Mozilla Forbidden Practices wiki page [1]:
** Logotype Extension ** Due to the risk of misleading Relying Parties and the lack of defined validation standards for information contained in this field, as discussed here [2], CAs MUST NOT include the RFC 3709 Logotype extension in CA or Subscriber certificates. Please respond if you have concerns with this change. As suggested in this thread, we can discuss removing this restriction if/when a robust validation process emerges. - Wayne [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/nZoK5akw2c8/ZtF0WZY8AgAJ On Tue, Jun 18, 2019 at 6:47 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 14/06/2019 18:54, Ryan Sleevi wrote: > > On Fri, Jun 14, 2019 at 4:12 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> In such a case, there are two obvious solutions: > >> > >> A. Trademark owner (prompted by applicant) provides CA with an official > >> permission letter stating that Applicant is explicitly licensed to > >> mark the EV certificate for a specific list of SANs and and Subject > >> DNs with their specific trademark (This requires the CA to do some > >> validation of that letter, similar to what is done for domain > >> letters). > > > > > > This process has been forbidden since August 2018, as it is fundamentally > > insecure, especially as practiced by a number of CAs. The Legal Opinion > > Letter (LOL) has also been discussed at length with respect to a number > of > > problematic validations that have occurred, due to CAs failing to > exercise > > due diligence or their obligations under the NetSec requirements to > > adequately secure and authenticate the parties involved in validating > such > > letters. > > > > Well, that was unfortunate for the case where it is not straing parent- > child (e.g. trademark owned by a foundation and licensed to the company) > But ok, in that case the option is gone, and what follows below is moot: > > > > > Letter needs to be reissued for end-of-period cert > >> renewals, but not for unchanged early reissue where the cause is not > >> applicant loss of rights to items. For example, the if the > Heartbleed > >> incident had occurred mid-validity, the web server security teams > >> could get reissued certificates with uncompromised private keys > >> without repeating this time consuming validation step. > > > > > > EV certificates require explicit authorization by an authorized > > representative for each and every certificate issued. A key rotation > event > > is one to be especially defensive about, as an attacker may be attempting > > to bypass the validation procedures to rotate to an attacker-supplied > key. > > This was an intentional design by CAs, in an attempt to provide some > value > > over DV and OV certificates by the presumed difficulty in substituting > them. > > > > I was considering the trademark as a validated property of the subject > (similar to e.g. physical address), thus normally subject to the 825 day > reuse limit. My wording was intended to require stricter than current > BR revalidation for renewal within that 825 day limit. > > > 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
