Verified Mark Certificates Proposal: A Security Perspective
Google, Inc.weihaw@google.comSkye Logicworksthede@skyelogicworks.comGeneral
Application Area Working GroupLOGOTYPEemail
This document motivates the need for embedding logotypes in X.509
certificates along with the certificate validation process from a
security perspective.
Many Mail User Agents and mail systems provide logo imagery as avatars
as part of the user interface chrome. For branded email, the agents
and systems use different, proprietary methods for provisioning the
avatar which causes consistency problems. Instead there should a
common, internet scale, secure method to fetch the sender’s brand logo
indicators during message delivery which this document along with
others documents by the AuthIndicators Working Group (aka BIMI Working
Group) propose.
Given the potential for impersonation abuse if not safeguarded, the
proposal incorporates defense in depth as it assumes an adversarial
security model and that parties will attempt to exploit
sender/subscribers for their own criminal benefit. Due to this risk
of identity spoofing, a sender’s identity is verified by a Certificate
Authority (CA) that acts as a Mark Verification Authority (MVA) that
then issues X.509 certificate with this evidence as a Verified Mark
Certificate (VMC). One risk is that the MVA may fail to distinguish a
spoofed identity during their verification either by oversight or
intentionally. To enable detection, issued certificates are publicly
disclosed through permanent untamperable logs that can be verified by
receivers, trademark monitors, the trademark holders themselves, and
other interested parties. Because of this, email receivers will have
greater confidence that the sender’s logo is what the sender says they
are.
The logo may be presented to the recipient if the email is at a
minimum authenticated via SPF , or DKIM ,
and passes the DMARC policy check. Because this proposal
uses domain authentication and DMARC in order for the logo to be
shown, it incentivizes the use of these domain authentication and
authorization methods. These methods are important because they
provide a consistent means of protecting against an sender domain
spoofing. However the FTC Office of Technology Research and
Investigation in 2017 found that 66% of business mail domains did not
use DMARC. Logo carrying mail must also pass other receiver
requirements such as not phish and not spam per their own policies.
Domain-based authentication methods SPF, and DKIM, enables the email
receivers’ automated anti-abuse systems to tie together emails sent by
the same sender to generate accurate per domain reputations that allow
them to filter abusive emails. The Verified Mark Certificate contains
curated sender’s metadata, that provides additional signals for
anti-phishing.
This document builds on the more generalized brand logo association
drafts that is specified in and
. This document is meant to
motivate the purpose for Verified Mark Certificates, and is purely
informative. The Roadmap section calls out where normative documents
are needed.
The , dated February 6, 2019
aka the “Assertion Record” specification, states as its objectives
the following goals:
No dependency on new Internet protocols or services for indicator registration or revocationIncremental deploymentPolicies solely published in BIMI DNS (TXT) recordDelegation by logo owners to third party logo providersScalability of brand associations across internet scale of domainsUniformity of brands displayed
(BIMI stands for Brand Indicators for Message Identification) The
Assertion Record draft uses SPF/DKIM/DMARC for message verification.
It defines optional header metadata and defaults to determine from
where to fetch the logo policy and locator from BIMI DNS TXT records.
From these, the receiver can generate a URL to fetch the logo. It
succeeds with the above goals, however it admits an important
limitation in that it does not specify "verification and reputation"
mechanisms and depends on them to prevent abuse. This document
describes solutions for those limitations.
Because some of the uses of branded email are high-value
transactional and business emails, there is the possibility the
protocol might be abused. Consequently the following is a
threat model to identify security weaknesses in the above
protocol. Malicious senders may spoof trusted identities for
phishing or spam by copying brand identities or by creating a
similar but confusable logo, served from their domain with their
own domain authentication. A adversary could:
game the receiver’s reputation system by using automated networks to send good email traffic and then launch an attack.related concern, is the problem of low traffic senders that receivers will have difficulty determining reputation.
An explicit definition of trustworthiness may be helpful establishing a reputation in these circumstances.
Another attack is to exploit the vulnerability of the email
system by injecting emails crafted by the adversary that use the
good sender's identity. While BIMI uses message authentication
through SPF/DKIM/DMARC that is meant to prevent this type of
spoofing, the adversary could exploit domains with weak
authentication via:
overly broad SPF policies acceptance policiesweak DKIM keys
Fortunately good senders can easily fix this. The adversary
could exploit weaknesses in DNS integrity as message
authentication depends on the integrity of the SPF/DKIM/DMARC
records which may be attacked through DNS cache poisoning or
man-in-the-middle (MitM). While such attacks seem far fetched,
the Snowden
disclosures show that nation-state adversaries have been
able to mount such attacks. Unfortunately deployment of DNS
protection through DNSSEC seems
to be stalled.
The dated on 6 Feb 6 2019
aka “Receivers Guidance” extends and provides best practices for
the Assertion Records draft. It notes the use of Verified Mark
Certificates which is new certificate issued by Mark Verifying
Authorities (MVA) to resist the spoofing attacks though with
limited details on validation and usage. The Receivers Guidance
document states receivers should work with multiple MVAs to
allow the successful untrust of any one malicious MVA. It also
calls for receivers to partner with Dispute Resolution Agencies
to handle trademark conflicts as well as acknowledges the courts
primacy for conflict resolution. It has other guidance: it
notes that receivers MTA may fetch and store the logo for the
MUA or it may have the MUA fetch it itself. It also provides
deployment guidance on domain authentication and DMARC.
The Receiver Guidance document references an AuthIndicators
Working Group document “Verified
Mark Certificates Usage (for review)” dated 23 October
2018 for details about Verified Mark Certificates. That
document is a specification on the handling of Verified Mark
Certificates by the receiver MTA and recipient MUA. It defines
the VMC validation and fetch process designed to protect the
privacy for the recipient from the sender- VMC fetch occurs at
delivery time, and cached by the MTA for use by the MUA, thus
view time usage of the VMC is hidden from the sender. Similarly
Certificate Revocation Lists (CRLs) are specified to allow for
offline revocation checking of the certificate. (There is the
related scenario of keeping private the use of the VM
Certificate content by the recipient from the receiver. This
hasn’t been specified in any of the documents, but a likely
solution would be embed the logo as a new header for use by the
MUA)
Notably those two documents avoid detailed discussion on the use
of Verified Mark Certificates for which this document tries to
fill in. Moreover, there are potential operational risks with
using curated information provided by X.509 certificates that
this document discusses next.
Experience using identity carrying certificates have
identified several important issues. An adversary attempting
to spoof an identity might try to exploit weaknesses in
certificate issuance validation.
Lax or intentionally malicious validation by CA/MVA may allow an adversary to impersonate with a copied or look alike identity.Ambiguities in the registered identity that the CA/MVA checks against may allow an adversary to obtain an “legitimate” identity for spoofing. Note that arguably the CA/MVA validation is considered successful here.
Carroll demonstrated in 2017 that ambiguities caused by different jurisdictions allowed him to obtain a web EV certificate for "Stripe, Inc." in Kentucky that could have allowed him to spoof the better known "Stripe, Inc" in Delaware. While browsers displays differences in country jurisdiction, it does not show state level information, and even if it did, it is doubtful users would notice. The analog for logos is that an adversary that desires spoofing logos in one jurisdiction would register similar or identical logos in another.Burton similarly demonstrated that he could obtain a web EV certificate for a misleading company name with a positive sounding security message e.g. "Identity Verified". The analog logo attack might be that the adversary registers a checkmark or padlock logo.
"Cousin marks" are similar but legitimate logos add another dimension of confusability as illustrated by this list. This confusability of this list seems to be caused by the trademark registration agency allowing similar logos when the company’s line of business don’t overlap.
With these spoofing attacks, one issue has been understanding the
scope of the attack i.e. given one bad certificate, if there are other
ones. Lack of global visibility in what has been issued has
historically made this problematic.
The largest deployed set of these identity carrying certificates has
been web Extended Validation (EV) where the subscribers legal identity
gets additional validation. Web sites uses these EV certificates get
additional chrome e.g. historically a green “bar” containing the
company name and padlock indicator. However operational experience
has indicated problems with this approach:
Jackson et al. found that using the web EV green padlock UI as a positive security indicator was not effective in helping users distinguish good websites from phishing as users did not notice the indicators. Company names sometime are not familiar to users. For example Google’s parent company name is “Alphabet Inc” which likely isn’t as familiar as “Google”.
This section specifies issuing a BIMI-specific X.509 certificate
that binds logos and other information to domains and to a legal
entity. CA/MVAs validate the binding and the X.509 CA based PKI
proves to all parties that this validation was done. These
certificates are called Verified Mark Certificates (VMC or VM
Certificates aka Mark Verified Certificates or MVC in some of our
other documents). This document primarily works with the use of
registered trademarks as it provides a useful legal framework to
establish VMC upon, however the AuthIndicators working group is
evaluating how to expand that to include other non-registered
identities.
Existing work provides specification for brand logos in X.509 PKIX
certificates as specified in and . The logo images can be embedded within the X.509
certificate as a subject extension using a DATA URL mentioned
in and specified in . The certificate
subject identifier describes a legal owner of the brand that can be
used for verification, and a DNS domain that matches the sender's
email address domain. The validation of these identities can follow
the procedures in CABF EV
baseline 1.6 with additional guidelines specific for BIMI as
described in these Guidelines
for Issuance of Verified Mark Certificates v0.97.
The Verified Mark Certificate must chain-up to a well known public
trust anchor i.e. a well known Certificate Authority certificate
issuer. This provides a cryptographic means to prove that a domain
owns a brand to the relying party as long as they can trust the
transitive issuing policy. If the logo bearing certificate is a CA
certificate, then it must be name constrained to the owning domain or
subdomain. This prevents the brand from being wrongly associated with
some non-owning domain for some child entity certificate issued from
the CA certificate.
allows the specification of only one logo per certificate. The issuer may need to issue multiple certificates that bear different logos for the brand. The appropriate logo is optionally selected by the BIMI email header as mentioned in or defaults to the default for the organizational domain name.
The Verified Mark Certificate issuance process builds upon the web
Extended
Validation (EV) certificates issuance guidelines, with
appropriate extensions as described Guidelines
for Issuance of Verified Mark Certificates v0.97. In
particular the brand ownership must undergo rigorous validation by
the issuing CA back to that legal entity, including explicit
face-to-face identity validation of the applicant. CAs already have
experience validating internet domain ownership back to legal
entities for the web EV program, and it would be reasonably feasible
for them to examine brand IP as well since these may be registered in
government trademark registries i.e. the logos must match a
registered trademark as described later. In addition brand names may
also be specified and found in those registries, as often they are
more easily recognized than the owning company’s name. CAs
performing these additional vetting steps would act as the Mark
Verifying Authorities (MVA) mentioned earlier. Further, the
requesting party for the certificates must meet certain minimum
identification and formation requirement e.g. be an incorporated
company, government body or registered non-profit known in the public
record. The requesting party’s legal address is disclosed in the
certificate for identification by the recipient and other interested
parties following the practices of the trademark jurisdiction. For
example here's the link
to USPTO FAQ, and the link
for EU (on page 3). This also in some hopefully limited
circumstance may help an aggrieved party serve legal notice.
In summary the VMC Guidelines validation process proves that:
Legal entity is legitimateDomain names are controlled by the organizationPerson requesting the certificate
Duly and currently authorized to do so by the organizationWho they say they areLegal entity has the rights to display the trademark logo (design mark) and optionally name (text mark)
BIMI-aware email receivers and/or mail clients should maintain their
own trusted BIMI CA/MVA root certificate store programs, or otherwise
rely on a program by another receiver. Such programs would manage a
fixed set of BIMI root certificates managed much like browser root
certificates. Most importantly these BIMI root certificate set owners
must create a security program to monitor the performance of CA/MVA to
adhere to their CPS much like the browser programs. A fixed root
certificate set creates certainty for the sender and recipients and
mitigates some BIMI header attacks. Certain receivers could publish
their root CAs, which would make it possible for intended certificate
subscribers to identify supported CAs. It also moves much of the
security work to the email receivers from the sender, which are better
positioned to do this work due to their security staffing and
association with browser security teams (with their expertise in X.509
PKI security).
We also propose that these certificates be published in
Certificate Transparency logs analogous to those
operated for web EV certificates. Certificate Transparency (CT)
logs are append only which provides protection against
equivocation i.e. manipulating the logs to show different views
to different requesters. A VM Certificate proves that it is
published in a CT log by including a SCT extension generated
when logged. All relying parties must check for the presence of
the valid SCT, and reject the certificate if it is not present.
Mandatory publishing provides global transparency that makes it
easier to detect other similar impersonation attacks or
mis-issuance. Global transparency provides certainty once a
problem has been detected that it can be fully remedied and
contained.
While RFC3709 may allow an external logo with a secure hash
which may be convenient, an adversary may simply not supply
potentially incriminating logo during an investigation. Instead
we propose embedding the logos in the Verified Mark Certificate.
With this the VMC CT log also provides a catalog of curated
logos and their ownership in a machine readable form that may
then be used by anti-abuse systems for use as reference
identities.
This document proposes that the major mail systems
using VMC along with VMC issuing CAs should run their own
publicly visible CT logs. While logging may be done
collaboratively, there must always be enough diversity so that
multiple logs are available under separate ownership to prevent
conflict of interest. Mail systems can elect to require logging
to their CT log in order to show the logos.
While some companies (e.g. Google) already actively monitors the
CT logs for misissuance, many companies don’t that should
monitor CT logs. This document encourages the development of
log monitoring services in particular visual logo monitoring to
protect brands from spoofing. For example, it is conceivable
that a CA may be interested in providing issuing and monitoring
service for brands as part of their commercial offering. Along
those lines there are companies specialized in mark monitoring
e.g. MarkMonitor that
might be interested. Automated visual recognition of logos is a
capability commercially available e.g. top
8 list.
Beyond that we also propose research into pre-publication of the
certificate in the CT logs before issuance that allows trademark
monitors to detect and block issuance if necessary. These monitors
would follow the log to look for trademark infringement, improperly
created certificates, and other abuses, and can file complaints to the
log. If the conflict is not initially resolved between the parties on
he log, then the trademark owners have access to the courts.
Assuming the research into CT with preview, which is being
investigated by the AuthIndicators working group, proves its
feasibility, this can potentially be followed up with standards work.
Using registered trademark helps clarifies ownership of the logo, and
raises the difficulty of succeeding at impersonation. The registration
process in many jurisdictions requires that the trademark be
distinctive and non-confusable with another. To enforce this, many
jurisdictions use a public review period and brands already employ
brand monitors
to protect the trademarks. As part of this review, many jurisdictions
have tests for objectionable or deceptive marks e.g. “Identity
Verified”. It also provides a central authority that documents
existing trademarks where an issuing CA/MVA can match the submitted
embedded logo to the documented trademark. If there is a dispute
between non-fraudulent parties, registration provides access to the
courts, and consequently trademark conflict resolution becomes a
process of following the court process. The certificate identifies
the trademark owner in case it is necessary to start those legal
proceedings. One issue is jurisdiction as trademarks laws and practices
differ. This proposes that the smallest scope should be nation
level where trademark law is well established. Trademarks may
also be registered internationally (across 90+ countries) via the
Madrid union and due to the universal first world coverage of the
Madrid union and largely the rest of the world, such a trademark
can be considered global jurisdiction. Similarly well known
regional, multi-country jurisdictions e.g EU should be
distinguishable as well. The country code information can be
specified in the certificate trademark jurisdiction field.
Display of the brand logo/name information should follow where the
information is valid, and this can be done by displaying the logo
only when the client is within the jurisdiction to the best of the
client's ability e.g. GPS on mobile devices, and IP geolocation on
desktop computers. A second closely related issue is the strength
of a particular jurisdiction trademark review and legal system to
prevent fraudulent trademarks. A concern is that they may differ
in their ability to prevent spoofing. The AuthIndicators Working
Group in conjunction with the CA/MVA and mail systems will review
and publish findings on the strength of particular jurisdictions.
International cross border registration or multiple jurisdiction
registration maybe helpful when some countries have better
trademark databases than others and should be encouraged.
This document extends the supported types in to include Verified Mark Certificates
but does not preclude the other logo image types mentioned in there.
In fact this proposal explicitly calls for supporting other logos
policies as the requirements in this document may be too onerous.
There are many reasonable use cases as documented in VMC
Guidelines document section 5 that don’t have registered
trademarks, or need VMC validation. Those other scenarios may use base
images types as allowed in or may
be X.509 certificates perhaps following their own validation profile
but won’t be described as Verified Mark Certificates. Furthermore
there may be non-branded scenarios but validateable scenarios such as
profile picture of an individual that could be embedded in VM
Certificates. Ultimately we want allow senders and receivers
flexibility in choosing which security, authentication and
authorization profile they wish to support and use.
The format of the logo is governed by and
. This document proposes that the logo media
be encapsulated and represented as SVG vector graphics so
that the image representation supports arbitrary visual rescaling.
This has several advantages. First, the logo image will always
appear sharp no matter the display resolution. Brand owners would
likely prefer the brand logo to appear in the client without image
display artifacts like pixelation. Second, having the ability to
render the logo in arbitrary many sizes assists in creating logo
detection neural networks as it eases training those neural networks.
The general idea is for automatic creation of the training dataset is
creations of different appearances of the logo with different sizes
and locations. Such logo detection neural networks assists in
automated detection and trademark abuse prevention both in the avatar
and the message body. A third advantage of standardizing on one
scalable image format is that it makes logo similarity comparison
more deterministic.
One issue is the security of SVG. specifies restrictions on the SVG to secure it:
Use SVG Tiny profileNo scriptNo external resource references
Only images that meet these requirements from RFC6170 are acceptable for use with BIMI and must be validated by the CA/MVA.
Certificates that claim to Verified Mark Certificates that do not
follow these specifications must be ignored by the receivers and mail
clients, meaning that mail associated with these certificates would
have no brand symbol attached in the UI. Aside from the obvious
safety benefits, this provides an incentive for certificate issuers
and brand-owning domain registrants to follow these requirements.
Also, receivers are not bound to show the logo if they believe the
message is malicious or fraudulent such as when the receiver believes
the message is spammy or phishy. As noted above, when the mail client
believes that the user is outside the jurisdiction of the trademark,
then the logo should not be shown. If the Verified Mark Certificate
has expired, the mail client should not show the logo, though still
permitted to do so for UI continuity. If the Verified Mark
Certificate is revoked, the mail client must not show the logo.
This normative description of this section is found in the Verified Mark Certificate Usage document, and the content here is provided to expand upon that description.
A BIMI-aware IMAP client or proprietary client upon receiving a BIMI
verified message fetches the logo and displays the logo alongside the
message both in message view and threaded view. It should be placed
in a location distinct from the message body, in a way that prevents
message body content from spoofing the logo. It should be visually
distinct from non-BIMI verified messages as many mail clients provides
the means to display a profile image that might be used to spoof a
BIMI verified logo. Some ideas are to make the BIMI verified logo
larger, different shape or use animation. Also the UI should support
display of extra descriptive information in case the recipient is
unfamiliar with the logo. This could be a tooltip or card panel.
This information should include the curated trademark name name if
available, description of the sender, and the jurisdiction of the logo
from the Verified Mark Certificate subject. As the ability of users
to understand
and recognize the logo across different mail user agents
depends on consistency, AuthIndicators working group should create a
voluntary guideline and encourage standard behavior across the email
clients. This guideline should updated periodically with input from
all BIMI members developing mail clients, taking into account current
and future mail client UIs. As noted earlier there are circumstances
where the mail client does not display the logo, and instead reverts
to the non-BIMI display behavior.
The proposal in this document attempts to create defense in
depth. If a malicious domain attempts to spoof a brand using
the techniques in this document, there are several preventative
safeguards. In order for the malicious domain to create and use
a Verified Mark Certificate, they must convince a CA/MVA to
issue one that they can publish. For arbitrary claimed
logos/names the CA/MVA vetting process should be able to detect
the spoofed trademark i.e. lack of a registered trademark, and
prevent them from being issued. A malicious domain could
register a similar confusable trademark, but some of these will
be prevented by the trademark registration review process. For
those that are registered, these may pass CA/MVA validation. If
CT with preview becomes reality and these certificates are
pre-published in that previewable log as proposed earlier,
trademark monitors can detect spoofed trademark, block issuance
and if necessary file a court action against the owner of the
wrongly claimed trademark. When the certificate has already
been issued, the aggrieved owner can go to court. Upon court
resolution against the infringing confusable logo/name (or upon
an injunction issued prior to a final resolution), the CA/MVA
can revoke the Verified Mark Certificate. A malicious domain
may try to forge email with a valid RFC822.FROM domain aligned
with a valid brand bearing domain and BIMI header that uses that
brand, but whose body contains spam or phishing. This should
fail SPF/DKIM message authentication which prevents the brand
logo from being shown. The logos provided in the VMC can be
used for anti-phishing models to help prevent spoofing of
legitimate mails. At the final step this proposal provides
visual branding imagery to help the recipient identify the
sender. Visual security indicators have been a controversial topics
since “Why
Johnny Can’t Encrypt” which noted that users have a hard
time understanding security concepts. As noted earlier, subsequent
research indicated that web EV security indicators did not
seem to have an effect on stopping phishing as users seemingly
tend to ignore positive security indicators. More recent by Felt
et al. provided a more nuanced view in that positive
security indicators have some effect on user decision making but
was weaker than negative indicators. Research is needed to see if
that brand recognition can have an effect albeit perhaps more
weakly on security decisions. Users already have a positive
association with brands since brand owners are incentivized to
build brand equity by associating their brand with a quality
product or service. Brand owners then go about educating
consumers, allowing them to have strong
brand recall and discrimination. This research is ongoing
in the AuthIndicators working group. Care must be taken though
because the adversary will try to spoof positive security
indicators which will dupe
the user.
The proposed updates to BIMI in this document improve its security
profile, but there still are some security weaknesses for an adversary
to exploit. First, if SPF message authentication is used, it is
subject to MitM message modification. Second, both SPF/DKIM message
authentication are subject to DNS record attacks either through MitM
or DNS cache poisoning. Third, BIMI depends on three separate
mechanisms- DKIM or SPF/DMARC/BIMI to work right. A relatively simple
improvement to both reduce failure modes and attack surface is to
mandate the use of DKIM style full body message authentication to
resist message modification and use the private-key associated with
the Verified Mark Certificate to sign the DKIM signature. Verified
Mark Certificate aware receivers can use the certificate public key to
verify the message signature contained in the DKIM header, and can
skip the DKIM DNS record lookup. For backwards compatibility this
verification can still leverages DKIM with its headers, and DNS record
with the same public key as Verified Mark Certificate, which allows
non BIMI-aware email receivers to use the DKIM for message
authentication. While this still uses DNS to locate information and
even allows the use of the DKIM public key, receivers aware of
Verified Mark Certificates do not need to depend on DNS to assert
identity and instead uses cryptographic proof via X.509 issuer-signed
certificate that chains up to a CA root certificate instead. Care
must be taken with approach to prevent downgrade attacks say between
the approach in this section and that of the rest of this document.
Because of the additional complexity and newness, this idea is
relegated to future discussion.
This informational document describes the rationale for Verified
Mark Certificates. This presumes several normative,
specification documents: 1) Verified Mark Certificate profile
and policy, 2) Verified Mark Certificate handling by the
receivers and 3) Certificate Transparency for Verified Mark
Certificates that includes a preview process. The BIMI profile
and policy document should be reviewed and published through a
policy directing body such as the CA/Browser Forum or the
AuthIndicators Working Group. The protocol to fetch and handle
Verified Mark Certificate by the receivers document should be
reviewed and published by the IETF. Lastly the concept of CT
logging with preview needs detailed review by the community and
may be submitted at an academic conference/workshop. Assuming a
satisfactory outcome, the final form of the preview work too
should be published through the IETF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
.