That argument applies to every extension not expressly permitted by the BRs. Even if I just put a number in s private extension, a relying party could be led to think jts their age. Can we better define what could constitute as potentially misleading extensions? Without that definition, this is the same as saying mo additional extensions are allowed, which is clearly not the intent of the existing language. ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of Corey Bonnell via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: Wednesday, June 12, 2019 4:52:39 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Logotype extensions
On Tuesday, June 11, 2019 at 7:49:31 AM UTC-4, Jeremy Rowley wrote: > We wanted to experiment a bit with logotype extensions and trademarks, but > we heard from the CAB Forum that whether inclusion is allowed is subject a > bit to interpretation by the browsers. > > > > >From the BRs section 7.1.2.4 > > "All other fields and extensions MUST be set in accordance with RFC 5280. > The CA SHALL NOT issue a Certificate that contains a keyUsage flag, > extendedKeyUsage value, Certificate extension, or other data not specified > in section 7.1.2.1, 7.1.2.2, or 7.1.2.3 unless the CA is aware of a reason > for including the data in the Certificate. CAs SHALL NOT issue a Certificate > with: a. Extensions that do not apply in the context of the public Internet > (such as an extendedKeyUsage value for a service that is only valid in the > context of a privately managed network), unless: i. such value falls within > an OID arc for which the Applicant demonstrates ownership, or ii. the > Applicant can otherwise demonstrate the right to assert the data in a public > context; or b. semantics that, if included, will mislead a Relying Party > about the certificate information verified by the CA (such as including > extendedKeyUsage value for a smart card, where the CA is not able to verify > that the corresponding Private Key is confined to such hardware due to > remote issuance)." > > > > In this case, the logotype extension would have a trademark included (or > link to a trademark). I think this allowed as: > > 1. There is a reason for including the data in the Certificate (to > identify a verified trademark). Although you may disagree about the reason > for needing this information, there is a not small number of people > interested in figuring out how to better use identification information. No > browser would be required to use the information (of course), but it would > give organizations another way to manage certificates and identity > information - one that is better (imo) than org information. > 2. The cert applies in the context of the public Internet. > Trademarks/identity information is already included in the BRs. > 3. The trademark does not falls within an OID arc for which the > Applicant demonstrates ownership (no OID included). > 4. The Applicant can otherwise demonstrate the right to assert the data > in a public context. If we vet ownership of the trademark with the > appropriate office, there's no conflict there. > 5. Semantics that, if included, will not mislead a Relying Party about > the certificate information verified by the CA (such as including > extendedKeyUsage value for a smart card, where the CA is not able to verify > that the corresponding Private Key is confined to such hardware due to > remote issuance). None of these examples are very close to the proposal. > > > > What I'm looking for is not a discussion on whether this is a good idea, but > rather is it currently permitted under the BRs per Mozilla's > interpretation. I'd like to have the "is this a good idea" discussion, but > in a separate thread to avoid conflating permitted action compared to ideal > action. > > > > Jeremy Absent policy surrounding the validation and encoding of Logotype data, I believe that the use of the Logotype extension to convey identity information may be fraught with security and privacy problems. A brief read of RFCs 3709 and 6170 raises several concerns: 1. Where are the image and audio assets stored? Will the CA allow for Applicants to specify an arbitrary URI for assets, or will the CA host them, or will the assets be encoded directly in the certificate using data URIs? The first two options have ramifications regarding client tracking, or even allowing attackers to suppress the retrieval of logo assets (thus providing for a potentially inconsistent UI between clients). This is compounded by the fact that the RFCs only allow retrieval via plaintext HTTP and FTP. I’m guessing the third option (“data” URI) is a non-starter due to certificate size limitations. 2. The RFCs do not put a hard requirement on the minimum size of images and length of audio files. What’s the minimum acceptable size of images to ensure that the trademark is clearly conveyed to Relying Parties? Is a 5-second clip from the Subject’s radio jingle sufficiently clear identity information? 3. Perhaps minor, but RFC 3709 specifies that clients MUST support SHA-1 for hashing assets. This is undesirable, especially given that attacks against SHA-1 are becoming increasingly practical. Given the concern about suppressing the retrieval of the trademark information and the lack of specification to ensure clear, unambiguous images/audio, I believe that 7.1.2.4.b is applicable here in that there is the possibility to mislead Relying Parties. As such, I believe that before CAs begin embedding the Logotype extension in certificates, the relevant RFCs need to be profiled (or updated, as applicable) and policy developed surrounding the validation and encoding of trademark information in the Logotype extension. Thanks, Corey _______________________________________________ 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
