On 14/06/2019 04:16, Corey Bonnell wrote:
On Thursday, June 13, 2019 at 2:04:48 AM UTC-4, kirkhal...@gmail.com wrote:
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 would be a great advance, and
is something that enterprises very much want. They believe that identity
information verified by a trusted third party (such as a CA) protects their
customers and protects their brand. They would very much like logos to be
included.
Let's work together cooperatively on this project to resolve any issues.
Hi Kirk,
In the case of Subway that you mentioned, how would the CA go about confirming that the
Applicant-provided trademark serial number is correctly registered to their Organization? Both
trademarks you provided list the registrant as "Subway IP Inc." on the corresponding
USPTO pages, not "Franchise World Headquarters LLC" (which is the O RDN value in the EV
certificate). Would the CA merely match on address in the case of a mismatch, or is there some
other method to rectify this name difference?
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). 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.
B. Applicant conglomerate uses the same legal entity for the certificate
application and trademark registration (not always possible if other
legal issues take priority for the applicant, such as keeping their
online webshop legally separate from their core IP assets).
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
