Please refer to the following entries in the Working Group's Wiki for relevant background information: WhatIsASecurePage
This section is normative.
Public key certificates (see [RFC3280]) are widely used in TLS, 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 Web user agents.
Web 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 to) vary by CA and are not available in any useful sense to Web user agents.
The Basic Path Validation algorithm (section 6 of [RFC3280] ) verifies the binding between the subject distinguished name and/or subject alternative name, and the subject public key, based on a path of certificates that leads to a trust anchor. As part of Basic Path Validation, Basic Certificate Processing is performed. This processing includes a verification of certificate status at the current time.
There are two common problems with this: firstly status verification is often not performed by Web user agents, for example due to firewall problems. Secondly, expired certificates frequently lead to the presentation of essentially spurious warnings to users. Less commonly not-yet-valid certificates cause a similar problem.
We therefore define a Relaxed Path Validation algorithm. [Definition: Relaxed Path Validation ] which differs from Basic Path Validation in its handling of certificate validity and status; specifically:
Note that this variant of Basic Path Validation does not require a real time source.
A trust anchor represents an authoritative entity represented via 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 data.
Trust anchor installation is typically handled by Web user agent vendors and systems administrators, based on out-of-band information. Note that trust anchor update is therefore often handled as part of Web user agent or operating system software update.
However, current Web 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) certiicates that cannot be currently verified using the Basic (or Relaxed) Path Validation algorithm may trigger current Web user agents to offer the user a choice to accept the certifiate in any case, sometimes for a single session, sometimes for all future sessions involving that certificate.
[Definition: A trust anchor or certificate is interactively accepted if the acceptance was caused through a user interaction that happens whlie 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 a browser's store of trust roots, then that certificate is not considered accepted interactively.
Please refer to the following entries in the Working Group's Wiki for relevant background information: RecommendationDisplayProposals/EVCerts
Some trust anchors adhere to broadly accepted industry standards (e.g. [EVSSLCERT]) that involve some level of guarantee that certificates chaining up to those roots embody augmented assurance and can therefore be treated more favourably in terms of the primary security indicators. In order to allow a Web user agent to provide such special treatment, the trust anchor, and possiblly 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 identifiiers.
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. Web 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.
Web user agents MUST establish that a trust anchor is [Definition: AA-qualified ] through some out of band mehcanism consistent with the relevant underlying augmented assurance specification.
Marking a trust anchor as AA-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 AA-qualified as part of a different interaction. Implementations MAY make user interfaces available for the purpose of designating AA-qualified trust roots. Such user interfaces MUST be focused on this specific task. In particular, the notions of an AA-qualified trust root and an interactively accepted trust root are mutually exclusive.
[Definition: An Augmented Assurance Certificate (AAC) 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 asurance specification supported by the Web user agent. The certificate chain for such a certificate MUST be validated up to a trust root that is recognized as AA-qualified by the user agent.]
Implementations MUST NOT use Relaxed Path Validation if the trust anchor is AA-qualified.
It is expected that it will generally be the case that Issuer and Subject information included in AACs is intended to be displayed to users.
Self-signed certificates (SSC) 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.
SSCs provide confidentiality protection services against passive attackers. No binding of a third-party asserted identity to the cryptographic key is achieved; SSCs are, in particular, not attested certificates.
Repeated interactions with the same web site (as identified by authority and port segments of the URI) over an extensive time period that are TLS-protected and that involve the same SSC can however provide sufficiently strong evidence that the user is achieving protection against an active attacker as well. This kind of "leap of faith" is known as a common practice in deployments of the Secure Shell Connection Protocol [RFC4254].
The period starting from the time when a particular SSC and web site are first seen by a Web user agent, until that SSC and web site combination is considered (by the Web user agent) to be sufficiently secure is the [Definition: "probation period."]
The required duration of the probation period for a self-signed certificate is implementation-specific.
[Definition: (normative) A Self-Signed Certificate (SSC) is called proven for a destination if it has been used for TLS-protected interactions with resources whose URIs share the same authority (domain) and port number for longer than the probation period.]
Note that a self-signed certificate can only be proven for a specific destination, for example, it is possible that some web server could be distributed where every instance of the web server makes use of the same SSC.
The same SSC SHOULD NOT be considered proven for more than one web site.
The issue of how to update proven SSCs is hard. That can happen if either a MITM attack is under way, or if a web server is completely regenerated, say after a disk crash. ISSUE-114
Much of the material in this section could be applied to anycontainer for key material, including certificates from unknown CAs, and anonymous key exchange algorithms. At the same time, some information about the invalidity of certificates might be gained from certificates that don't lead back to a known trust anchor. ISSUE-103
The term [Definition: validated certificate ] is used to denote a public key certificate that has been veriifed by chaining up to a locally configured trust anchor. The set of trust anchors used by a given Web User agent is implementation-dependent. Essentially, this represents the "normal" certificate case, as opposed to the "stronger" AAC and "weaker" SSC.
Since AACs chain up to a "special" trust anchor, all valid AACs are also validated certificates.
SSCs MAY be considered as validated certificates by Web user agents for the specific destination for which they are proven. However, Web user agents MUST NOT conclude that any assertions that may be included in an SSC are valid. SSCs MUST NOT be considered validated certificates during the probation period.
Please refer to the following entries in the Working Group's Wiki for relevant background information: RecommendationDisplayProposals/Letterhead
RFC 3709 [RFC3709] defines a certificate extension to embed three kinds of logotypes with an X.509 certificate, for use with public key certificates [RFC3280] or attribute certificates [RFC3281].
[Definition: The Community logotype [RFC3709] is a logotype that identifies a community.]
[Definition: The Issuer Organization logotype [RFC3709] is a logotype that identifies the organization that issued the certificate.]
[Definition: The Subject Organization logotype [RFC3709] is a logotype that identitifies the organization to which the certificate was issued.]
RFC 3709 also specifies a format to encapsulate audio data with certificates. Not yet covered. ISSUE-120
Logotype certificates that are validated, are considered validated certificates.
SSCs MUST NOT be considered logotype certificates.
Is that ok? Do we ever want to use a logo from an SSC?
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 URL is dereferenced are subsumed under this
term.
[Definition:
(normative) An HTTP transaction is TLS-desired if the resource is
identified through a URL with the https URI scheme.]
[Definition:
(normative) An HTTP transaction is TLS-protected if an upgrade
according to [RFC2817] is performed successfully,
or if the resource was identified through a URL with the https
URI scheme, the TLS handshake is finished successfully, and the HTTP
transaction has occured through the TLS channel.]
Note that an HTTP transaction may be considered TLS protected even though weak algorithms
(including NULL encryption) are negotiated.
[Definition: (normative)
An HTTP transaction is strongly TLS-protected if it is TLS-protected, an https URL was used,
and the following conditions are true:]
If we are react to certs that don't match a URL then we need a well defined matching rule. This should probably be solved by way of some appropriate normative references. ISSUE-106, ISSUE-121
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.
[Definition: (normative) Strong TLS algorithms are defined as the algorithms recommended by [ref-ALGORITHMS].]
What reference should we have here? ISSUE-128
[Definition: (normative) 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:]
DH_anonWeakly 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.
[Definition: A change of security level occurs when actual interactions do not match expectations established by user context, interaction history, or user agent state.] This section elaborates on the conditions under which such changes should be considered to have occured.
Implementations MAY assume that a change of security level has occured for reasons not covered in this specification.
If an validated certificate is used in a TLS-protected interaction, and strong TLS protection cannot be achieved, then Web user agents MUST assume that a change of security level has occured:
When users follow hyperlinks, user agents are often presented with a chain of redirections, maybe based on HTTP codes, maybe based on scripting. In some situations, the link might be located on a TLS-secured page, yet, the chain of redirects involves plain HTTP, or weakly TLS-protected HTTP transactions, thereby leading to additional exposure, with a high potential for user confusion.
Web user agents MUST assume that a change of security level has occured when a user interaction with a TLS-secured page causes dereferencing of a URL leads to a chain of Web transactions that:
Note that this applies whether or not the resource in which the non-interactive chain of redirections terminates is TLS protected in any manner. In particular, even if the retrieval of the final resource in the chain of redirections is strongly TLS protected, clients MUST assume that a change of security levels has occured. Also note that this section is not limited to HTTP level redirection mechanisms; it also covers redirections that are caused by scripting or HTML constructs.
Also note that this section does not apply to situations in which, e.g., an HTML form is served by way of a strongly TLS protected transaction, but the user's input is submitted through plain HTTP.
Web user agents that have found a resource strongly TLS protected during past interactions MUST consider an interaction with the same resource as a change of security level if that interaction is not strongly TLS protected. Web user agents that have found a resource strongly TLS protected with an Augmented Assurance Certificate SHOULD consider an interaction with the same resource as a change of security level if that interaction is not strongly TLS protected with an Augmented Assurance Certificate.
Examples of such situations include a site that usually presents a validated certificate that now changes to presenting an SSC, or a site that changes its SSC.
The current language is setting the stage for rather intrusive error handling when a site changes self-signed certificates from ones that a client is used to. This might be undesirable. ISSUE-114
When an user manually enters a https scheme URL, this
indicates an expectation of strongly TLS-protected behavior. If the
resulting transaction is not strongly TLS-protected, a change of security level is considered to
have occured.