Public key certificates (see [PKIX]) are widely used in TLS [SSLv3] [TLSv11]
[TLSv12], but have been the basis
for the generation of many inappropriate warnings and other
dialogs for users. This section describes some
modifications to current certificate processing aimed at
improving this aspect of handling web security context and
defines some new terms describing various cases related to
certificate handling in user agents.
User agents can base their acceptance of certificates
that are presented by Web servers on various sources,
including user action, previous interactions involving the
same certificate, or, as more traditionally assumed, on
validation of a certificate chain where each certificate is
issued by a Certification Authority (CA). The practices
used by CAs (and the information attested) vary by CA and
are not available in any useful sense to Web user
agents.
A trust anchor represents an authoritative entity
represented by a public key and associated data. The
public key is used to verify digital signatures and the
associated data is used to constrain the types of
information for which the trust anchor is authoritative.
Relying parties use trust anchors to determine if
digitally signed information objects are valid by
verifying digital signatures using the trust anchor's
public key and by enforcing the constraints expressed in
the associated certificate data.
Trust anchor installation is typically handled by user
agent vendors, systems administrators and device
manufacturers, based on out-of-band information. Note
that updating trust anchors is therefore often handled as
part of user agent or operating system software
updates.
However, current user agents sometimes support the
interactive acceptance of a trust anchor during a
session, based on user interaction. Most users cannot
sensibly decide how to handle such interactions.
Similarly, end-entity (e.g. web server) certificates
that cannot be currently verified using the Basic Path
Validation algorithm may trigger current user agents to
offer the user a choice to accept the certificate in any
case, sometimes for a single session, sometimes for all
future sessions involving that certificate, possibly
scoped to specific host and port combinations.
[Definition: A trust anchor or certificate is
interactively accepted if the acceptance was
caused through a user interaction that happens while the
user is focused on a primary task unrelated to trust and
certificate management.]
For example, if a web server certificate is presented
for acceptance by a user during ordinary Web
interactions, and is accepted by the user, then this
matches the test for interactive acceptance. If, however,
a systems administrator (or user) adds a trust anchor's
certificate to an agent's store of trust roots, then that
certificate is not considered interactively accepted.
Some trust anchors adhere to documented broadly
accepted practices (e.g. [EVTLSCERT]). These involve some level of
guarantee that certificates chaining up to those roots
embody augmented assurance and can therefore be treated
more favorably in terms of the primary security
indicators. We call such certificates "Augmented
Assurance Certificates".
[Definition:
An Augmented Assurance Certificate is a public key
certificate where the issuer asserts that the subject
entity has been authenticated by means of some process
that adheres to the requirements of an augmented
assurance specification supported by the user agent. The
certificate chain for such a certificate MUST be
validated up to a trust root that is recognized as
augmented assurance qualified by the user agent.]
This specification does not define what an "augmented
assurance qualified trust root" is, except to note that
this designation is made by user agents through an out of
band mechanism consistent with the relevant underlying
augmented assurance specification.
Marking a trust anchor as augmented assurance
qualified is a security-critical step and most often will
involve the use of some application-specific out-of-band
mechanism.
Implementations MUST NOT enable users to
designate trust roots as augmented assurance qualified as
part of a unrelated interaction. In particular,
the notions of an augmented assurance qualified trust
root and an interactively accepted trust
root are mutually exclusive.
In addition to the out of band designation process
described above, the trust anchor, and possibly all
certificates in a path chaining up to such a trust anchor
may need to be specially marked, e.g. through the use of
specific policy object identifiers.
The specific marking mechanisms to be used and the
special treatment to be afforded to such certificates are
out of scope of this document, but will typically be
covered by the underlying augmented assurance
specification. User agent implementers determine the set
of such standards that they support and the associated
special treatment to apply, other than as outlined below,
where we impose some consistency requirements on the
handling of this type of certificate.
To derive a human-readable subject name
from an augmented assurance certificate, user agents
SHOULD use the Subject field's Organization (O) and
Country (C) attributes. They MUST
use information that is subject to the certificate
authority's additional assurances, as documented in the
user agent's conformance statement.
Note: Should certificates arise in the future that
provide strong assurance of the holder's identity, but do
not include an organization attribute, then user agents
can make use of the additional assurance level and
identity information without violating this
specification. Such future certificates could, for
example, include high assurance certificates for
individuals.
The term [Definition:
validated certificate ] is used to denote a public
key certificate that has been verified by chaining up to
a locally configured trust anchor. The set of trust
anchors used by a given Web User agent is
implementation-dependent.
Since Augmented Assurance Certificates chain up to a
"special" trust anchor, all valid Augmented Assurance
Certificates are also validated certificates.
Certificates or certificate chains that are pinned to a particular
destination are not considered validated
certificates by virtue of being pinned.
The notion of a validated certificate in this
specification corresponds to the domain validated
certificate commonly deployed on the Web. This type of
certificate attests to a binding between a domain name
registration and a key pair; additional certificate
attributes are often not validated.
Self-signed certificates (SSC) which are not trust
anchors by themselves are commonly used for appliances
and web sites catering to small groups of users, and
essentially serve as a container for cryptographic key
material in a key exchange that is not verified by any
third party. Certificate chains that lead up to custom
root certificates which are not part of the user agent's
store of trust roots are sometimes used similarly.
In both situations, use of TLS provides
confidentiality protection services against passive
attackers. No binding of a third-party asserted identity
to the cryptographic key is achieved. In both cases, the
certificates are not considered validated certificates.
Using Key Continuity Management [KCM], user agents can use
self-signed certificates (or certificates that chain up
to an untrusted root) to determine that they are
consistently communicating with the same end entity,
thereby defending against active attacks as well. Simply
put, if a Web site consistently presents the same
self-signed certificate (or the same certificate chaining
up to the same untrusted root) to a client, then this can
be strong evidence that protection against an active
attacker has been achieved as well. Conversely, a change
of certificates for the same site can be evidence that a
man in the middle attack occurs -- or it can merely
indicate that the legitimate site has changed to a
different certificate.
User agents MAY support [Definition: pinning] a self-signed
certificate or more generally a certificate chain that
leads to an untrusted root certificate to a particular
Web site, to enable behavior based on recorded state
about certificates shown previously by the same
site. Such behavior includes, e.g., warning users
about changes of certificates, and not showing warning
messages if a site shows a certificate consistent with
previous visits.
The interaction that enables
users to pin a certificate to a destination SHOULD NOT
cause a self-signed certificate to be pinned to more than
one site, identified through URI scheme, domain, and
port. The interaction MUST NOT
cause an untrusted root certificate to be accepted
automatically for additional sites.
The most common mechanism for applying TLS to the Web is
the use of the https URI scheme [RFC2818]; the alternative upgrade
mechanism [RFC2817] is used
rarely, if at all. For the purposes of this specification,
the most relevant property of [RFC2818] is that the URI used to
identify a resource includes an assertion that use of TLS
is desired.
This specification uses the term [Definition: HTTP transaction ] regardless of
whether any kind of TLS protection was applied; in
particular, the transactions arising when an
https URI is dereferenced are subsumed under
this term. [RFC2616]
[Definition: An HTTP transaction is
TLS-protected if the resource was identified through
a URI with the https URI scheme, the TLS handshake was
performed successfully, and the HTTP transaction has
occurred through the TLS channel.]
Note that an HTTP transaction may be considered
TLS protected
even though weak algorithms (including NULL
encryption) are negotiated.
[Definition: An HTTP transaction is strongly
TLS-protected if it is TLS-protected, an https URL was
used, strong TLS
algorithms were negotiated for both confidentiality and
integrity protection, and at least one of the following
conditions is true:]
- the server used a validated certificate that
matches the dereferenced URI; or
- the server used a self-signed certificate that was
pinned to the
destination; or
- the server used a certificate chain leading to an
untrusted root certificate that was pinned to the destination.
TLS modes that do not require the server to show a
certificate (such as the DH_anon mode) do not
lead to a strongly TLS-protected transaction.
The ability to provide privacy and secure the connection
between a user agent and web server is in part determined
by the strength and capabilities of the TLS protocol and
underlying cryptographic mechanisms. The TLS protocol is
versioned to keep pace with protocol features and cipher
suites that are available. Cipher suites are grouped
according to algorithms and the key length used by
cryptographic functions to provide cipher strength.
When this document speaks of [Definition: Strong TLS
algorithms], then the following must hold:
- No version of the TLS protocol that suffers known
security flaws has been negotiated. At
the point of writing of this document, versions of SSL
prior to SSLv3 [SSLv3] MUST NOT
be considered strong.
- A cipher suite has been selected for which key and
algorithm strengths correspond to industry practice.
At the time of writing of this document,
the "export" cipher suites explicitly forbidden in
appendix A.5 of [TLSv11] MUST
NOT be considered strong.
What set of algorithms is considered as strong by a
given implementation must be described in any conformance
claim against this specification, see 3.4 Conformance
claims.
[Definition: An HTTP transaction is weakly
TLS-protected if it is TLS-protected, but strong TLS
protection could not be achieved for one of the following
reasons:]
- TLS handshake used an anonymous key exchange
algorithm such as
DH_anon
- the cryptographic algorithms negotiated are not
considered strong
- certificates were used that are not either validated certificates,
or self-signed certificates pinned to the destination (see
5.1.4 Self-signed
Certificates and Untrusted Root
Certificates)
Weakly
TLS-protected interactions may provide security
services such as confidentiality protection against passive
attackers, or integrity protection against active attackers
(without confidentiality protection). These properties are
often desirable, even if strong TLS protection cannot be
achieved.
If a given Web page consists of a single resource only,
then all content that the user interacts with has security
properties derived from the HTTP transaction used to
retrieve the content.
[Definition: A Web page is called TLS-secured
if the top-level resource and all other resources that can
affect or control the page's content and presentation have
been retrieved through strongly TLS protected HTTP
transactions. ]
[Definition: A Web page is called mixed
content if the top-level resource was retrieved through
a strongly TLS protected HTTP transaction, but some
dependent resources were retrieved through a weakly
protected or unprotected HTTP transaction.]
This definition implies that inline images, stylesheets,
script content, and frame content for a secure page need to
be retrieved through strongly TLS protected HTTP
transactions in order for the overall page to be considered
TLS-secured.
Any UI indicator used to signal the
presence of Augmented Assurance certificates MUST NOT
signal the presence of such a certificate, unless the page
is TLS-secured,
i.e., all parts of the page are loaded from servers
presenting at least a validated certificate, over
strongly TLS-protected
interactions.
For relevant security considerations, see 8.6 Mixing Augmented
Assurance and Validated Certificates.
This section covers TLS-related error conditions, and
maps them to the classes of error handling interactions
(see 6.4 Error handling and
signaling) that are used when these conditions
arise.
If multiple error conditions apply, the
most severe signaling level currently known MUST be used,
as defined in 6.4 Error
handling and signaling.
When, during TLS negotiation, the certificate chain
presented by the server does not lead to a trusted root
certificate, and the certificate chain presented was not
pinned to the
destination, the following applies:
- Error signaling of class warning or
higher (6.4.2
Warning/Caution Messages , 6.4.3 Danger Messages) MUST
be used to signal the error condition.
- User agents MAY offer a possibility
to pin newly encountered certificates to the
destination.
Note that, when untrusted certificates are accepted
without user interaction, an additional exposure to
man-in-the-middle attacks is created. See 8.1 Active attacks during initial TLS
interactions for a more detailed discussion of
this scenario.
When certificate information is
presented in the interactions described in this section,
then human-readable information from certificates MUST
NOT be presented as trustworthy unless it is attested.
E.g., a self-signed certificate's Common Name or
Organization attribute MUST NOT be displayed, even if
that certificate is pinned to a destination.
User agents MAY display this information in
a dialog or other secondary user interfaces reachable
from the warning or error messages specified
here.
When, during TLS negotiation, the
end-entity certificate presented or one of the
intermediate certificates in the certificate chain are
found to have been revoked, error signaling of class
danger (6.4.3 Danger
Messages) MUST be used.
When, during TLS negotiation, the
end-entity certificate presented or one of the
intermediate certificates in the certificate chain are
found to have expired, error signaling of class danger
(6.4.3 Danger
Messages) MUST be used.
When the URI corresponding to the
transaction does not match the end-entity certificate
presented, and a validated certificate is used,
then error signaling of level danger (6.4.3 Danger Messages) MUST be
used.
If TLS negotiation otherwise fails,
error signaling of level danger (6.4.3 Danger Messages) MUST be
used.
When TLS error conditions occur, user
agents MAY choose to abort the connection without any
further user interaction. The guidelines in this
section apply when user agents choose to cause a user
interaction in the case of TLS error conditions. Note
that user agents may combine both practices: E.g., an
interactive approach may be chosen for the top-level
frame of a Web page, but a non-interactive approach may
be chosen for inline content. It is expected that the
XMLHttpRequest specification [XHR]
will include a non-interactive approach as well.
User agents that use third party
services or heuristic approaches to assess the possible
danger of a pending Web transaction MUST use error
signaling of class danger (6.4.3 Danger Messages) to
signal positively identified dangers, e.g., identified
malicious downloads or exploits of user agent
vulnerabilities.
To signal risks that are identified
with high likelihood, but involve further user decisions
(e.g., phishing heuristics were triggered), error
signaling of class warning or above (6.4.2 Warning/Caution
Messages , 6.4.3
Danger Messages) MUST be used.