Re: Logotype extensions
On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, 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 Sorry – the USPTO links for the Subway registered trademarks in my last message expired. Go to this search page http://tmsearch.uspto.gov/bin/gate.exe?f=searchss&state=4808:d53jqt.1.1 And search on these two Serial or Registration Numbers to see the Subway logo and word mark: 5373029 5601308 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
On Tuesday, June 11, 2019 at 2:49:31 PM UTC+3, 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 Jeremy is correct - including strongly verified registered trademarks via extensions in EV certs is permitted (i.e., not forbidden) by BR Section 7.1.2.4. Confirming registered trademarks (whether logos, word marks, or both in a combined mark) to include in an EV cert would be very easy for a CA. Here are the steps: 1. Complete EV validation of the Organization 2. Applicant sends CA its USPTO logo or wordmark Registration Number and SVG file of logo to include in EV cert CA validates: (a) Confirm logo and/or wordmark is registered to Organization in USPTO online data base, and (b) Compare USPTO image with SVG file received to confirm they are the same logo. 3. CA inserts (a) name of Trademark office with the logo and/or wordmark registration, (b) the Registration Number, and (c) the SVG file in the EV certificate to be available to browsers and applications to display if desired. Adding validated logos to EV certificates has the benefit of allowing browsers and apps to choose to display the logo (with registered word mark, if desired) in the UI, and would solve the concern that some have expressed that users don't always recognize the corporate name of a familiar brand when it's displayed in the current EV UI. For example, consider the EV website of the food chain "Subway" - www.subway.com. The current EV UI shows "Franchise World Headquarters, LLC [US]" which is correct but not very friendly for users. What if instead a browser or app displayed the verified trademark and/or word mark owned by Subway? See these two records from the US Patent and Trademark Office: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:6juyuh.2.20 http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4804:6juyuh.2.14 Adding strongly verified marks to EV certificates w
SwissSign: CP/CPS certificate profile issue
1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. In Bug 1551364 "SwissSign: "Some-State" in stateOrProvinceName", Ryan Sleevi reported potential issues in relation to OIDs in the CP/CPS of SwissSign Gold PKI (https://bugzilla.mozilla.org/show_bug.cgi?id=1551364#c2). In the subsequent internal analysis SwissSign found the following: - The SwissSign Gold CP/CPS with OID 2.16.756.1.89.1.2.1.7 is missing on the online archive under https://repository.swisssign.com and is only available in the internal archive. - For the SwissSign Gold CP/CPS with OID 2.16.756.1.89.1.2.1.7, the certificate profile for end user certificates for G22 in section 7.1.2 f) was still 2.16.756.1.89.1.2.1.6 instead of 2.16.756.1.89.1.2.1.7 - For the SwissSign Gold CP/CPS with OID 2.16.756.1.89.1.2.1.8, the certificate profile for end user certificates for G22 in section 7.1.2 f) was still 2.16.756.1.89.1.2.1.6 instead of 2.16.756.1.89.1.2.1.8 - By applying the certificates profiles out the CP/CPS correctly, SwissSign issued certificates with a reference to an OID that did not match the applicable valid CP/CPS for these certificates. Concretely: i) between 14.09.2017 - 12.10.2017 under the wrong OID 2.16.756.1.89.1.2.1.6 instead of 2.16.756.1.89.1.2.1.7. ii) between 12.10.2017 - 16.07.2018 under the wrong OID 2.16.756.1.89.1.2.1.6 instead of 2.16.756.1.89.1.2.1.8. - Note: No EV certificates are affected by this issue Because of the above findings we additionally checked the SwissSign Silver product line which resulted in similar findings - The SwissSign Silver CP/CPS with OID 2.16.756.1.89.1.3.1.8 is missing on the online archive under https://repository.swisssign.com and is only available in the internal archive. - For the SwissSign Silver CP/CPS with OID 2.16.756.1.89.1.3.1.7, the certificate profile for end user certificates for G22 in section 7.1.2.6 was still 2.16.756.1.89.1.3.1.6 instead of 2.16.756.1.89.1.3.1.7. - For the SwissSign Silver CP/CPS with OID 2.16.756.1.89.1.3.1.8, i) the title page showed for this CP/CPS the OID is 2.16.756.1.89.1.3.7 instead of 2.16.756.1.89.1.3.8 in contrast to section 1.2 ii) the certificate profile for end user certificates for G22 in section 7.1.2.6 was still 2.16.756.1.89.1.3.1.6 instead of 2.16.756.1.89.1.3.1.8 - By applying the certificates profiles out the CP/CPS correctly, SwissSign issued certificates with a reference to an OID that did not match the applicable valid CP/CPS for these certificates. Concretely: i) between 15.09.2017 - 16.10.2017 under the wrong OID 2.16.756.1.89.1.3.1.6 instead of 2.16.756.1.89.1.3.1.7. ii) between 16.10.2017 - 28.06.2018 under the wrong OID 2.16.756.1.89.1.3.1.6 instead of 2.16.756.1.89.1.3.1.8. As part of the risk impact analysis, all changes in the concerned CP/CPS were revisited. All changes were related either to a change in regulations not directly impacting the issued certificate (i.e. CT Log and CAA) respectively to an audit finding requiring a statement on used key length and algorithms for the subscriber’s QCSD in the CP/CPS. Therefore, the risk analysis did not show any security impact for our customers nor for the community by further usage of these certificates. The detailed impact was shared with TÜV Trust IT to confirm our interpretation. We did not identify any relevant changes that would put the customer at risk by usage of the impacted certificates. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. [May-14-2019 Post Ryan Sleevi] Notification of potential OID divergence in one of the CP/CPS Gold documents [May-15-2019] Start of validation of potential issue [May-17-2019] SwissSign validates the issue in the 2 CP/CPS Gold mentioned above. [May-20-2019] Confirmation of issue on a partial set of certificates and decision to initiate a full analysis. Risk impact analysis recorded a formal issue triggering a revocation of the concerned certificates, no security impact for our customers nor for the community by further usage of these certificates was identified. [May-21-2019] Information of auditor (TüV Trust IT) about issue. [May-23-2019] Management Board acknowledged the issue and the associated risks. [May-27-2019] First results of analysis syndicated and validated on Gold product line. Decision to extend analysis to Silver product line. [May-29-2019] Results confirmed for Gold product line scope, information to the management board of the additional extend, information of the auditor about the need to post a misissuance report to Bugzilla
Re: Logotype extensions
I agree with Corey. On Wed, Jun 12, 2019 at 4:28 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That argument applies to every extension not expressly permitted by the > BRs. Yup. It definitely puts the onus on the CA to demonstrate how they're not violating, and to put a clear and cogent argument forward as to how it meets that constraint. > Even if I just put a number in s private extension, a relying party could > be led to think jts their age. I think one way a CA would respond to a complaint that this was misissuance would be to refer to an appropriate specification or draft that defines how it is not. > 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. Minimally, Subject Identity Information (or some modification therein to indicate it's applicable to the Subscriber/Applicant/Subject and not just the Certificate's Subject distinguishedName field) This would mean, for example, that any element of logoType, LEI, or alternative naming schemes would fundamentally be SII. The CA would have to demonstrate how the information included was verified, but also not applicable to the Subscriber/Applicant/Subject. The downside to this approach is that it's still not sufficient to address "stupidity". For example, I can imagine a CA would exploit such a language loophole by, say, including the Mozilla logo in a certificate for Google, arguing that they verified that the Mozilla logo had been verified as belonging to Mozilla. However, that should still be a 'clear' violation of 7.1.2.4(b). A more extreme version would be to argue that 7.1.2.4(b) would forbid anything without an appropriate definition for how that information is verified in a public context, and what those standards might be (e.g. W3C, IETF, ETSI?) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Logotype extensions
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 on behalf of Corey Bonnell via dev-security-policy 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
