On Fri, Jul 5, 2019 at 8:04 PM Jeremy Rowley via dev-security-policy < [email protected]> wrote:
> I think my biggest concern is that there hasn't actual been any proof that > this would mislead relying parties. You'd actual have to have Mozilla do > something with it first. I don’t think this is the only argument against, to be clear. In the context of the interoperable Web PKI, given the fact that the LogoType extension is itself insecure if processed, and there are clients that process it, do you think the ecosystem health argument is relevant? That is, the same as when NULs were embedded in Common Names - valid according to the specs, but results in insecure risk to clients. The general badness can apply to any extension in a cert. No actual risk > has been pointed out other than a CA may put something in a cert and a > relying part may view the cert somehow to see the information. This is > true with every extension, not just logo types. That’s not true. There’s been ample discussion of risk. Risk to relying parties that rely on the reproducibility of certificates, for example, running into issues with reproducing the logos. There was ample criticism of the specific proposal here in the IETF when this was standardized, from 2002-2003. Happy to provide links to those archives, but it’s worth realizing even then, the notion of LogoType in EEs, and Logos in particular, were seen as dangerous. For example, it’s technically impossible to constrain such certificates; does that mean Mozilla Policy should update to ensure that TCSCs are no longer seen as such for any CA that issues such certificates? There’s a fundamental ecosystem risk by introducing such information. It adds more challenges to timely revocation and replacement of the certificate. Perhaps a policy should be that no CA that has ever had delays in revocation, due to difficulties replacing certificates, should be allowed to issue such certificates? Just to reiterate: - It causes harm to extant software and users - It makes it harder to reissue and replace certificates - The CA intentionally is introducing risks and challenges to the appropriate disclosure of such certificates, to the point I think no extant CT Log could safely accept certificates from CAs that issued such certificates, and that would seem a perfectly reasonable CT Log decision. - It is unquestionably Subscriber information with no safe or reasonable way to reliably validate, especially in an unambiguous way - There is no reasonable way for potential victims of CA misissuance to check or verify. That is, there is no programmatic way that works to compare such certificates, and the notion of “Use ML” misses the idea of adversarial examples. The reality is that the Web PKI needs an allowlisted profile, because such additional information is actively harmful to a more secure, more reliable Web. You can find plenty of discussion, even two decades ago, about the value of having that information expressed separately - e.g. as has been discussed in the context of GLEIF, in which the identifier links to a separately maintained and updatable database. There are issues with that, for sure, as have also been discussed over the years. I am wholly supportive of the proposed policy change. It will actively be harmful to the Web ecosystem if CAs were to try to conflate TLS server certificates with such unnecessary information. > ________________________________ > From: dev-security-policy <[email protected]> > on behalf of Wayne Thayer via dev-security-policy < > [email protected]> > Sent: Friday, July 5, 2019 5:53:24 PM > To: mozilla-dev-security-policy > Subject: Re: Logotype extensions > > 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 < > [email protected]> 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 < > > > [email protected]> 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
