FW: Proposed amendment to RFC2109
Jaye, Dan (DJaye@engagetech.com)
Thu, 3 Apr 1997 21:23:01 -0500
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------ =_NextPart_000_01BC4075.2177C560
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Here is the proposal:
>----------
>From: Jaye, Dan
>Sent: Thursday, April 03, 1997 9:18 PM
>To: 'http-wg@cuckoo.hpl.hp.com'
>Cc: 'ahyde@focalink.com'; 'rodger@worldnet.atg.net'
>Subject: Proposed amendment to RFC2109
>
>As promised, here is a description of our proposal to amend RFC2109
>to allow certification of unverifiable transactions.
>
>I have two questions in particular regarding this proposal:
>
>1) Should "certified" cookies be a third! type of cookie header
> [this is what we have written in the proposal] or can we
> incorporate the certificate as an option in the SetCookie2 header?
>
>2) Can we include this in the next version of RFC2109 or must it be a
> separate RFC?
>
>
>
------ =_NextPart_000_01BC4075.2177C560
Content-Type: text/plain; name="certifiers.txt"
Content-Transfer-Encoding: quoted-printable
HTTP STATE MANAGEMENT PROPOSAL FOR CERTIFIED COOKIES
March 30, 1997
1. ABSTRACT
This document specifies an addition to the state management protocol =
specified in RFC 2109. The intent is to provide a mechanism that allows =
user agents to determine the privacy policies of a server and to accept =
or reject cookies based on that policy. Allowing the user to decide =
whether to accept cookies based on how the server uses them provides far =
better control over privacy than just distinguishing between servers the =
users directly accesses (verified transactions) and those to which the =
user agent was redirected (unverified transaction.) It furthermore =
avoids unnecessarily precluding valid distributed applications.=20
To provide such information about server privacy behavior, we assume the =
existence of an independent certifying authority (or authorities), such =
as eTrust. The authority establishes levels of "trust" and can audit =
domains to determine their adherence to a given level. It then issues =
certificates to domains based on the trust level. Passing those =
certificates along with cookies allows the user-agent to support =
cookie-acceptance rules based on trust level.=20
This document describes a new header, Set-Cookie-Certifiers for sending =
certificates along with cookies. Set-Cookie2 would still be used to send =
the cookies. The new header would send certificates intended to verify =
the trust level of the domain issuing the cookies. This proposal does =
not alter any existing headers.
2. SCOPE OF THIS DOCUMENT
This document addresses only the requirement that it be possible to =
support state management policies at the user-agent that are based on =
level of privacy adhered to by the server domain. It has therefore not =
addressed some more general questions raised about the state management =
protocol, such as the domain-matching rules, or the definition of =
session itself. Those definitions are assumed in this document.
3. TERMINOLOGY
The terms user agent, client, server, origin server, FQHN, FQDN, =
request host, request-URI and proxy are used as in RFC 2109 on State =
Management. The terms domain-match, verified transaction and unverified =
transaction are defined in RFC2109, and those definitions are also used =
here.
The term certificate is used to mean an x.509 certificate as referred to =
in the SSL protocol document, and defined in the x.509 proposed =
specification[]
4. STATE MANAGEMENT PROTOCOL
4.1 SYNTAX
The syntax for the Set-Cookie-Certifier response header is:
Set-Cookie-Certifier =3D "Set-Cookie-Certifier: " certificates=20
certificates =3D x.509-Certificate (",")=20
X.509-Certificate is taken from the SSL Protocol[]. The full =
specification of x.509 can be found in []. This specification should =
follow the definitions in those documents.=20
The following is a summary version of the x.509 definition. It includes =
all the fields we use here.=20
x.509-Certificate =3D SEQUENCE {
certificateInfo CertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
CertificateInfo =3D SEQUENCE {
version [0] Version DEFAULT v1988,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
The token "signature" is the hashed value of CertificateInfo, encrypted =
with the Certificate Authority's private key, by the algorithm specified =
in signatureAlgorithm. Validity is a date range. Issuer is the name of =
the certificate authority. We will use different issuer names to convey =
different levels of certification. The subject name should contain the =
domain name to which the certification applies. Other fields are not =
used in this specification and their definitions can be found in the =
x.509 specification [] or the SSL Protocol specification [].
Informally, the syntax consists of the token "Set-Cookie-Certifier:" =
followed by a comma-separated list of certificates. Note that list of =
certificates applies to all cookies in the Set-Cookie2 header of the =
response . There is no need for separate certificates per cookie, since =
all cookies in the response come from the same server, and certificates =
belong to the server not the cookie. More than one certificate may be =
needed, however, since the server may own certificates from multiple =
certificate authorities, and any given user-agent may be able to accept =
certificates from only some authorities.
[NOTE: there is a comment in RFC2109 that states that a gateway may fold =
multiple Set-Cookie2 headers into a single header. It is assumed that =
such folding applies only to headers from the same origin server. If =
that is not the case, we will in fact have to include the certificate in =
the cookie itself.]
4.2 SERVER ROLE
Any server wishing to provide certified cookies must request a =
certificate from the certifying authority. Unlike the certification =
assumed in general for x.509 certificates, the certifying authority here =
must have the ability to evaluate the server domain and determine the =
trust level for which a certificate will be issued. That evaluation =
takes place outside the protocol described here. The actual certificate =
request can use the PKCS(10) protocol for certificate-requests [see..]. =
That protocol will provide the certifying authority with the =
CertificateInfo to be signed in the issued certificate. The certifying =
authority then provides the certificate to be included in the =
set-certified-cookie header.
The origin server initiates a session, if it so desires. To ensure that =
user-agents have the most complete information with which to determine =
whether to allow cookies to be set during this session, it initiates the =
session by including the header Set-Cookie-Certifier in addiiton to the =
Set-Cookie2 header. It includes in this header the set of certificates =
the server has been issued by various trust authorities. (In actuality, =
this protocol may in fact be useful for authentication in the a broader =
context than just privacy requirements.)=20
The origin server receives cookies from a user-agent in a cookie request =
header. This proposal does not modify the cookie request header =
definition. The server may choose to use or ignore cookies supplied in =
such request headers. Upon receipt of such a cookie, it can return the =
same or a different cookie in the response, or no cookie at all.=20
4.3 USER AGENT ROLE
The user agent receives cookies from an origin server in the =
Set-Cookie2 header and cookie certificates in the Set-Cookie-Certifier =
header. The agent can choose to ignore the Set-Cookie-Certifier header. =
If it chooses to use the certificate information, then it must validate =
the certificates and can then decide whether to accept the cookies based =
on the privacy level of the certificates.=20
User agents determine the policy for accepting or rejecting cookies. One =
suggested policy would be to accept cookies only from sites that are =
certified by an authority such as eTrust, regardless of whether the =
transaction is verified. User agents may also provide policy options =
that distinguish between verified and unverified transactions, for =
example by allowing all cookies in verified transactions and only =
certified cookies in unverified transactions.
The user agent must be able to accept certificates from the authority =
named as the issuer. It need accept only one certificate in the header =
to validate the cookies. Thus, a server may send all its certificates, =
not knowing which a given user agent might accept. Rejection of some is =
irrelevant, though it does consume processing time. If the cookie =
acceptance policy is based on certificates and the user agent cannot =
interpret any certificate, then it must reject the cookies in the =
response.=20
To ensure that the certificate is valid, the user agent decrypts the =
certificate's signature using the certifying authority's public key. =
That key can be obtained from the certifying authority by requesting =
it's own certificate, which includes its public key. Given that we =
expect few such certifying authorities, the user agent may choose to =
store keys from standard authorities to avoid extra round trips..
The issuer of the certificate indicates the certification authority, as =
well as the level of certification. Thus, if eTrust has 3 levels of =
certification, they will issue certificates as three different =
authorities. The user agent may have options that allow cookies to be =
stored only if they come from domains with an adequate level of privacy =
certification. To do so, the user agent maintains a list of the =
certificate authorities that guarantee appropriate privacy levels.=20
The subject field in the certificate names the domain for which the =
certificate is valid. The path of the cookie must domain-match the =
domain of a certificate if the cookie must be certified. It is the user =
agent's responsibility to ensure that domains are properly matched. If =
the user agent is set to accept all cookies then all certificate =
processing can be skipped.=20
This proposal does not alter the domain matching rules described in RFC =
2109. Those rules preclude sharing of cookies across some combinations =
of subdomains. The user agent must reject cookies if those =
domain-matching rules are violated.
4.4. CERTIFYING AUTHORITY ROLE
The certifying authority referred to in this document must be a neutral =
third party that can be trusted to accurately characterize the privacy =
behavior of web sites. ETrust is one such organization that might play =
this role. The issuing of certificates occurs outside the scope of this =
protocol, but the protocol depends on user trust in that authority. The =
certifying authority must understand the scope in which a certificate =
applies and the related domain-matching rules, to ensure that for all =
situations in which the certificate would be deemed to be applicable, =
the server(s) are in fact operating at the specified trust level. On =
receiving a certificate request, the authority must audit the site =
requesting the certificate and issue the appropriate level certificate. =
To issue the certificate, the authority hashed the CertificateInfo =
provided by the requester, encrypts that hash value with its private key =
and includes the resulting value as the signature in the certificate it =
issues. The authority must also be prepared to respond to requests for =
its certificate, which contains its public key. Certificate revocation =
is handled primarily via revocation lists, as with any x.509 certifier =
authority.
5. SUMMARY
This document presents an extension to the state management protocol =
defined in RFC2109. It describes only extensions to that protocol. Any =
parts of the state management not explicitly described here are assumed =
to remain as defined in RFC 2109.=20
The protocol described here allows a user agent to verify that the =
origin server is using cookies in a manner consistent with the privacy =
expectations of the user, by providing a certificate issued by a trusted =
authority.
- 1 -
------ =_NextPart_000_01BC4075.2177C560--