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
