FW: Proposed amendment to RFC2109

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?
>
>
>

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. 

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. 

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    = "Set-Cookie-Certifier: " certificates 
    certificates = x.509-Certificate (",") 

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. 

The following is a summary version of the x.509 definition. It includes all the fields we use here. 

    x.509-Certificate = SEQUENCE {
      certificateInfo CertificateInfo,
      signatureAlgorithm AlgorithmIdentifier,
      signature BIT STRING
      }

    CertificateInfo  = 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.) 

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. 


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. 

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. 

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. 

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. 

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. 

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 -