Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.7>
kv = "4" | "5"
Key-Name is the symbolic name to which this key is to be bound.
Ciphers is a list of ciphers for which this key is potentially
applicable (see the list of header ciphers in section 3.2.4.7). The
keyword 'null' should be used to indicate that it is inappropriate
for use with ANY cipher. This is potentially useful for exchanging
keys for MAC computation.
Lifetime is a representation of the longest period of time during
which the recipient of this message can expect the sender to accept
that key. 'this' indicates that it is likely to be valid only for
reading this transmission. 'reply' indicates that it is useful for a
reply to this message. If a Key-Assign with the reply lifetime
appears in a CRYPTOPTS block, it indicates that it is good for at
least one (but perhaps only one) dereference of this anchor. An
unspecified lifetime implies that this key may be reused for an
indefinite number of transactions.
Method should be one of a number of key exchange methods. The only
currently defined value is 'inband' referring to Inband keys (i.e.,
direct assignment).
This header line may appear either in an unencapsulated header or in
an encapsulated message, though when an uncovered key is being
directly assigned, it may only appear in an encrypted encapsulated
content. Assigning to a key that already exists causes that key to be
overwritten.
Keys defined by this header are referred to elsewhere in this
specification as Key-IDs, which have the syntax:
Key-ID = method ":" key-name
3.3.3.1. Inband Key Assignment
This refers to the direct assignment of an uncovered key to a
symbolic name. Method-args should be just the desired session key
encoded in hexidecimal as in:
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef
Short keys should be derived from long keys by reading bits from left
to right.
Note that inband key assignment is especially important in order to
permit confidential spontaneous communication between agents where
one (but not both) of the agents have key pairs. However, this
mechanism is also useful to permit key changes without public key
computations. The key information is carried in this header line must
be in the inner secured HTTP request, therefore use in unencrypted
messages is not permitted.
3.3.4. Nonces
Nonces are opaque, transient, session-oriented identifiers which may
be used to provide demonstrations of freshness. Nonce values are a
local matter, although they are might well be simply random numbers
generated by the originator. The value is supplied simply to be
returned by the recipient.
3.3.4.1. Nonce
This header is used by an originator to specify what value is to be
returned in the reply. The field may be any value. Multiple nonces
may be supplied, each to be echoed independently.
The Nonce should be returned in a Nonce-Echo header line. See section
4.1.1.
3.4. Grouping Headers With SHTTP-Cryptopts
In order for servers to bind a group of headers to an HTML anchor, it
is possible to combine a number of headers on a single S-HTTP
Cryptopts header line. The names of the anchors to which these
headers apply is indicated with a 'scope' parameter.
3.4.1. SHTTP-Cryptopts
This option provides a set of cryptopts and a list of references to
which it applies. (For HTML, these references would be named using
the NAME tag). The names are provided in the scope attribute as a
comma separated list and separated from the next header line by a
semicolon. The format for the SHTTP-Cryptopts line is:
SHTTP-Cryptopts =
"SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec> ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML anchor NAME attribute>
For example:
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSS
If a message contains both S-HTTP negotiation headers and headers
grouped on SHTTP-Cryptopts line(s), the other headers shall be taken
to apply to all anchors not bound on the SHTTP-Cryptopts line(s).
Note that this is an all-or-nothing proposition. That is, if a
SHTTP-Cryptopts header binds options to a reference, then none of
these global options apply, even if some of the options headers do
not appear in the bound options. Rather, the S-HTTP defaults found in
Section 3.2.4.11 apply.
4. New Header Lines for HTTP
Two non-negotiation header lines for HTTP are defined here.
4.1. Security-Scheme
All S-HTTP compliant agents must generate the Security-Scheme header
in the headers of all HTTP messages they generate. This header
permits other agents to detect that they are communicating with an
S-HTTP compliant agent and generate the appropriate cryptographic
options headers.
For implementations compliant with this specification, the value must
be 'S-HTTP/1.4'.
4.1.1. Nonce-Echo
The header is used to return the value provided in a previously
received Nonce: field. This has to go in the encapsulated headers so
that it an be cryptographically protected.
5. (Retriable) Server Status Error Reports
We describe here the special processing appropriate for client
retries in the face of servers returning an error status.
5.1. Retry for Option (Re)Negotiation
A server may respond to a client request with an error code that
indicates that the request has not completely failed but rather that
the client may possibly achieve satisfaction through another request.
HTTP already has this concept with the 3XX redirection codes.
In the case of S-HTTP, it is conceivable (and indeed likely) that the
server expects the client to retry his request using another set of
cryptographic options. E.g., the document which contains the anchor
that the client is dereferencing is old and did not require digital
signature for the request in question, but the server now has a
policy requiring signature for dereferencing this URL. These options
should be carried in the header of the encapsulated HTTP message,
precisely as client options are carried.
The general idea is that the client will perform the retry in the
manner indicated by the combination of the original request and the
precise nature of the error and the cryptographic enhancements
depending on the options carried in the server response.
The guiding principle in client response to these errors should be to
provide the user with the same sort of informed choice with regard to
dereference of these anchors as with normal anchor dereference. For
instance, in the case above, it would be inappropriate for the client
to sign the request without requesting permission for the action.
5.2. Specific Retry Behavior
5.2.1. Unauthorized 401, PaymentRequired 402
The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent
failures of HTTP style authentication and payment schemes. While S-
HTTP has no explicit support for these mechanisms, they can be
performed under S-HTTP while taking advantage of the privacy services
offered by S-HTTP. (There are other errors for S-HTTP specific
authentication errors.)
5.2.2. 420 SecurityRetry
This server status reply is provided so that the server may inform
the client that although the current request is rejected, a retried
request with different cryptographic enhancements is worth
attempting. This header shall also be used in the case where an HTTP
request has been made but an S-HTTP request should have been made.
Obviously, this serves no useful purpose other than signalling an
error if the original request should have been encrypted, but in
other situations (e.g. access control) may be useful.
5.2.2.1. SecurityRetries for S-HTTP Requests
In the case of a request that was made as an SHTTP request, it
indicates that for some reason the cryptographic enhancements applied
to the request were unsatisfactory and that the request should be
repeated with the options found in the response header. Note that
this can be used as a way to force a new public key negotiation if
the session key in use has expired or to supply a unique nonce for
the purposes of ensuring request freshness.
5.2.2.2. SecurityRetries for HTTP Requests
If the 420 code is returned in response to an HTTP request, it
indicates that the request should be retried using S-HTTP and the
cryptographic options indicated in the response header.
5.2.3. 421 BogusHeader
This error code indicates that something about the S-HTTP request was
bad. The error code is to be followed by an appropriate explanation,
e.g.:
421 BogusHeader Content-Privacy-Domain must be specified
5.2.4. 422 SHTTP Proxy Authentication Required
This response is analagous to the 420 response except that the
options in the message refer to enhancements that the client must
perform in order to satisfy the proxy.
5.2.5. 320 SHTTP Not Modifed
This response code is specifically for use with proxy-server
interaction where the proxy has placed the If-Modified-Since header
in the S-HTTP headers of its request. This response indicates that
the following S-HTTP message contains sufficient keying material for
the proxy to forward the cached document for the new requestor.
In general, this takes the form of an S-HTTP message where the actual
enhanced content is missing, but all the headers and keying material
are retained. (I.e. the optional content section of the CMS message
has been removed.) So, if the original response was encrypted, the
response contains the original DEK re-covered for the new recipient.
(Notice that the server performs the same processing as it would have
in the server side caching case of 7.1 except that the message body
is elided.)
5.2.6. Redirection 3XX
These headers are again internal to HTTP, but may contain S-HTTP
negotiation options of significance to S-HTTP. The request should be
redirected in the sense of HTTP, with appropriate cryptographic
precautions being observed.
5.3. Limitations On Automatic Retries
Permitting automatic client retry in response to this sort of server
response permits several forms of attack. Consider for the moment
the simple credit card case:
The user views a document which requires his credit card. The
user verifies that the DN of the intended recipient is acceptable
and that the request will be encrypted and dereferences the
anchor. The attacker intercepts the server's reply and responds
with a message encrypted under the client's public key containing
the Moved 301 header. If the client were to automatically perform
this redirect it would allow compromise of the user's credit
card.
5.3.1. Automatic Encryption Retry
This shows one possible danger of automatic retries -- potential
compromise of encrypted information. While it is impossible to
consider all possible cases, clients should never automatically
reencrypt data unless the server requesting the retry proves that he
already has the data. So, situations in which it would be acceptable
to reencrypt would be if:
1. The retry response was returned encrypted under an inband key
freshly generated for the original request.
2. The retry response was signed by the intended recipient of the
original request.
3. The original request used an outband key and the response is
encrypted under that key.
This is not an exhaustive list, however the browser author would be
well advised to consider carefully before implementing automatic
reencryption in other cases. Note that an appropriate behavior in
cases where automatic reencryption is not appropriate is to query the
user for permission.
5.3.2. Automatic Signature Retry
Since we discourage automatic (without user confirmation) signing in
even the usual case, and given the dangers described above, it is
prohibited to automatically retry signature enchancement.
5.3.3. Automatic MAC Authentication Retry
Assuming that all the other conditions are followed, it is
permissible to automatically retry MAC authentication.
6. Other Issues
6.1. Compatibility of Servers with Old Clients
Servers which receive requests in the clear which should be secured
should return 'SecurityRetry 420' with header lines set to indicate
the required privacy enhancements.
6.2. URL Protocol Type
We define a new URL protocol designator, 'shttp'. Use of this
designator as part of an anchor URL implies that the target server is
S-HTTP capable, and that a dereference of this URL should undergo S-
HTTP processing.
Note that S-HTTP oblivious agents should not be willing to
dereference a URL with an unknown protocol specifier, and hence
sensitive data will not be accidentally sent in the clear by users of
non-secure clients.
6.3. Browser Presentation
6.3.1. Transaction Security Status
While preparing a secure message, the browser should provide a visual
indication of the security of the transaction, as well as an
indication of the party who will be able to read the message. While
reading a signed and/or enveloped message, the browser should
indicate this and (if applicable) the identity of the signer. Self-
signed certificates should be clearly differentiated from those
validated by a certification hierarchy.
6.3.2. Failure Reporting
Failure to authenticate or decrypt an S-HTTP message should be
presented differently from a failure to retrieve the document.
Compliant clients may at their option display unverifiable documents
but must clearly indicate that they were unverifiable in a way
clearly distinct from the manner in which they display documents
which possessed no digital signatures or documents with verifiable
signatures.
6.3.3. Certificate Management
Clients shall provide a method for determining that HTTP requests are
to be signed and for determining which (assuming there are many)
certificate is to be used for signature. It is suggested that users
be presented with some sort of selection list from which they may
choose a default. No signing should be performed without some sort of
explicit user interface action, though such action may take the form
of a persistent setting via a user preferences mechanism (although
this is discouraged.)
6.3.4. Anchor Dereference
Clients shall provide a method to display the DN and certificate
chain associated with a given anchor to be dereferenced so that users
may determine for whom their data is being encrypted. This should be
distinct from the method for displaying who has signed the document
containing the anchor since these are orthogonal pieces of encryption
information.
7. Implementation Notes
7.1. Preenhanced Data
While S-HTTP has always supported preenhanced documents, in previous
versions it was never made clear how to actually implement them.
This section describes two methods for doing so: preenhancing the
HTTP request/response and preenhancing the underlying data.
7.1.1. Motivation
The two primary motivations for preenhanced documents are security
and performance. These advantages primarily accrue to signing but may
also under special circumstances apply to confidentiality or
repudiable (MAC-based) authentication.
Consider the case of a server which repeatedly serves the same
content to multiple clients. One such example would be a server which
serves catalogs or price lists. Clearly, customers would like to be
able to verify that these are actual prices. However, since the
prices are typically the same to all comers, confidentiality is not
an issue. (Note: see Section 7.1.5 below for how to deal with this
case as well).
Consequently, the server might wish to sign the document once and
simply send the cached signed document out when a client makes a new
request, avoiding the overhead of a private key operation each time.
Note that conceivably, the signed document might have been generated
by a third party and placed in the server's cache. The server might
not even have the signing key! This illustrates the security benefit
of presigning: Untrusted servers can serve authenticated data without
risk even if the server is compromised.
7.1.2. Presigned Requests/Responses
The obvious implementation is simply to take a single
request/response, cache it, and send it out in situations where a new
message would otherwise be generated.
7.1.3. Presigned Documents
It is also possible using S-HTTP to sign the underlying data and send
it as an S-HTTP messsage. In order to do this, one would take the
signed document (a CMS or MOSS message) and attach both S-HTTP
headers (e.g. the S-HTTP request/response line, the Content-Privacy-
Domain) and the necessary HTTP headers (including a Content-Type that
reflects the inner content).
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
Random signed message here...
This message itself cannot be sent, but needs to be recursively
encapsulated, as described in the next section.
7.1.4. Recursive Encapsulation
As required by Section 7.3, the result above needs to be itself
encapsulated to protect the HTTP headers. the obvious case [and the
one illustrated here] is when confidentiality is required, but the
auth enhancement or even the null transform might be applied instead.
That is, the message shown above can be used as the inner content of
a new S-HTTP message, like so:
SECURE * Secure-HTTP/1.4
Content-Type: application/s-http
Content-Privacy-Domain: CMS
Encrypted version of the message above...
To unfold this, the receiver would decode the outer S-HTTP message,
reenter the (S-)HTTP parsing loop to process the new message, see
that that too was S-HTTP, decode that, and recover the inner content.
Note that this approach can also be used to provide freshness of
server activity (though not of the document itself) while still
providing nonrepudiation of the document data if a NONCE is included
in the request.
7.1.5. Preencrypted Messages
Although preenhancement works best with signature, it can also be
used with encryption under certain conditions. Consider the situation
where the same confidential document is to be sent out repeatedly.
The time spent to encrypt can be saved by caching the ciphertext and
simply generating a new key exchange block for each recipient. [Note
that this is logically equivalent to a multi- recipient message as
defined in both MOSS and CMS and so care must be taken to use proper
PKCS-1 padding if RSA is being used since otherwise, one may be open
to a low encryption exponent attack [HAST96].
7.2. Proxy Interaction
The use of S-HTTP presents implementation issues to the use of HTTP
proxies. While simply having the proxy blindly forward responses is
straightforward, it would be preferable if S-HTTP aware proxies were
still able to cache responses in at least some circumstances. In
addition, S-HTTP services should be usable to protect client-proxy
authentication. This section describes how to achieve those goals
using the mechanisms described above.
7.2.1. Client-Proxy Authentication
When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that
(by whatever access control rules it uses) it requires to be S-HTTP
authenticated (and if it isn't already so), it should return the 422
response code (5.7.4).
When the client receives the 422 response code, it should read the
cryptographic options that the proxy sent and determine whether or
not it is willing to apply that enhancement to the message. If the
client is willing to meet these requirements, it should recursively
encapsulate the request it previously sent using the appropriate
options. (Note that since the enhancement is recursively applied,
even clients which are unwilling to send requests to servers in the
clear may be willing to send the already encrypted message to the
proxy without further encryption.) (See Section 7.1 for another
example of a recursively encapsulated message)
When the proxy receives such a message, it should strip the outer
encapsulation to recover the message which should be sent to the
server.
8. Implementation Recommendations and Requirements
All S-HTTP agents must support the MD5 message digest and MAC
authentication. As of S-HTTP/1.4, all agents must also support the
RSA-MD5-HMAC construction.
All S-HTTP agents must support Outband, Inband, and DH key exchange.
All agents must support encryption using DES-CBC.
Agents must support signature generation and verification using
NIST-DSS.
9. Protocol Syntax Summary
We present below a summary of the main syntactic features of S-
HTTP/1.4, excluding message encapsulation proper.
9.1. S-HTTP (Unencapsulated) Headers
Content-Privacy-Domain: ('CMS' | 'MOSS')
Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
Content-Type: 'message/http'
MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
<key-spec>
9.2. HTTP (Encapsulated) Non-negotiation Options
Key-Assign: <Method>','<Key-Name>','<Lifetime>','
<Ciphers>';'<Method-args>
Encryption-Identity: <name-class>','<key-sel>','<name-args>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Nonce: <string>
Nonce-Echo: <string>
9.3. Encapsulated Negotiation Options
SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
SHTTP-Privacy-Domains: ('CMS' | 'MOSS')
SHTTP-Certificate-Types: ('X.509')
SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband')
SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
'RC2-CBC' )
SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' |
'RC2-ECB')
SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
Your-Key-Pattern: <key-use>','<pattern-info>
9.4. HTTP Methods
Secure * Secure-HTTP/1.4
9.5. Server Status Reports
Secure-HTTP/1.4 200 OK
SecurityRetry 420
BogusHeader 421 <reason>
10. An Extended Example
We provide here a contrived example of a series of S-HTTP requests
and replies. Rows of equal signs are used to set off the narrative
from sample message traces. Note that the actual encrypted or signed
message bodies would normally be binary garbage. In an attempt to
preserve readability while still using (mostly) genuine messages, the
bodies of the requests have been base64 encoded. To regenerate actual
S-HTTP messages, it is necessary to remove the base64 encoding from
the message body.
10.1. A request using RSA key exchange with Inband key reply
Alice, using an S-HTTP-capable client, begins by making an HTTP
request which yields the following response page:
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate-Info: CMS,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
kiG9w0BBwEAAKCAM
IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
AAAAA==
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
<A name=tag1 HREF="shttp://www.setec.com/secret">
Don't read this. </A>
============================================================
An appropriate HTTP request to dereference this URL would be:
============================================================
GET /secret HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.2beta
Accept: *.*
Key-Assign: Inband,1,reply,des-ecb;7878787878787878
============================================================
The added Key-Assign line that would not have been in an ordinary
HTTP request permits Bob (the server) to encrypt his reply to Alice,
even though Alice does not have a public key, since they would share
a key after the request is received by Bob. This request has the
following S-HTTP encapsulation:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
+mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
1JLSAAAAAAAAAAAAAA==
============================================================
The data between the delimiters is a CMS message, RSA enveloped for
Setec Astronomy.
Bob decrypts the request, finds the document in question, and is
ready to serve it back to Alice.
An appropriate HTTP server response would be:
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.4
Content-Type: text/html
Congratulations, you've won.
<A href="/prize.html"
CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
claim your prize</A>
============================================================
This HTTP response, encapsulated as an S-HTTP message becomes:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl
nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7
AAAAAAAAAAA=
============================================================
The data between the delimiters is a CMS message encrypted under a
randomly-chosen DEK which can be recovered by computing:
DES-DECRYPT(inband:1,697fa820df8a6e53)
where 'inband:1' is the key exchanged in the Key-Assign line in the
original request.
10.2. A request using the auth enhancement
There is a link on the HTML page that was just returned, which Alice
dereferences, creating the HTTP message:
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
============================================================
Which, when encapsulated as an S-HTTP message, becomes:
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
============================================================
The data between the delimiters is a CMS 'Data' representation of the
request.
Appendix: A Review of CMS
CMS ("Cryptographic Message Syntax Standard") is a cryptographic
message encapsulation format, similar to PEM, based on RSA's PKCS-7
cryptographic messaging syntax.
CMS is only one of two encapsulation formats supported by S-HTTP, but
it is to be preferred since it permits the least restricted set of
negotiable options, and permits binary encoding. In the interest of
making this specification more self-contained, we summarize CMS here.
CMS is defined in terms of OSI's Abstract Syntax Notation (ASN.1,
defined in X.208), and is concretely represented using ASN.1's Basic
Encoding Rules (BER, defined in X.209). A CMS message is a sequence
of typed content parts. There are six content types, recursively
composable:
Data -- Some bytes, with no enhancement.
SignedData -- A content part, with zero or more signature
blocks, and associated keying materials. Keying materials
can be transported via the degenerate case of no signature
blocks and no data.
EnvelopedData -- One or more (per recipient) key exchange
blocks and an encrypted content part.
DigestedData -- A content part with a single digest block.
EncryptedData -- An encrypted content part, with key
materials externally provided.
Here we will dispense with convention for the sake of ASN.1-impaired
readers, and present a syntax for CMS in informal BNF (with much
gloss). In the actual encoding, most productions have explicit tag
and length fields.
Message = *Content
Content = Data | SignedData | EnvelopedData |
DigestedData | EncryptedData
Data = Bytes
SignedData = *DigestAlg Content *Certificates
*CRLs SignerInfo*
EnvelopedData = *RecipientInfo BulkCryptAlg
Encrypted(Content)
DigestedData = DigestAlg Content DigestBytes
EncryptedData = BulkCryptAlg Encrypted(Bytes)
SignerInfo = CertID ... Encrypted(DigestBytes) ...
RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
Appendix: Internet Media Type message/s-http
In addition to defining the S-HTTP/1.4 protocol, this document serves
as the specification for the Internet media type "message/s-http".
The following is to be registered with IANA.
Media Type name: message
Media subtype name: s-http
Required parameters: none
Optional parameters: version, msgtype
version: The S-HTTP version number of the enclosed message
(e.g. "1.4"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response".
If not present, the type can be determined from the
first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary"
are permitted.
Security considerations: this is a security protocol.
Bibliography and References
[BELL96] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash
Functions for Message Authentication", Preprint.
[FIPS-46-1] Federal Information Processing Standards Publication
(FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed
1988 January 22 (supersedes FIPS PUB 46, 1977 January
15).
[FIPS-81] Federal Information Processing Standards Publication
(FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[FIPS-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
[HAST86] Hastad, J., "On Using RSA With Low Exponents in a Public
Key Network," Advances in Cryptology-CRYPTO 95
Proceedings, Springer-Verlag, 1986.
[JOHN93] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D.,
"Design of the Commercial Data Masking Facility Data
Privacy Algorithm," Proceedings 1st ACM Conference on
Computer & Communications Security, November 1993,
Fairfax, VA., pp. 93-96.
[KRAW96b] Krawczyk, H. personal communication.
[LAI92] Lai, X. "On the Design and Security of Block Ciphers,"
ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax
Standard", PKCS-6, Nov 1, 1993.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet
Text Messages", STD 11, RFC822, August 1982.
[RFC-1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
1319, April 1992.
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321,
April 1992.
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", RFC1421, February 1993.
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC-1779] Kille, S., "A String Representation of Distinguished
Names", RFC1779, March 1995.
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC2045, September 1993.
[RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC
1738, December 1994.
[RFC-1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Muliparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC1847, October 1995.
[RFC-1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME
Object Security Services", RFC1848, October 1995.
[RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC1864, October 1995.
[RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1" RFC2616, June 1999.
[RFC-2617] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A. and L. Stewart, "HTTP Authentication: Basic
and Digest Access Authentication", RFC2617, June 1999.
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC2104, February
1997.
[SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For
HTML", RFC2659, August 1999.
[VANO95] B. Prennel and P. van Oorschot, "On the security of two
MAC algorithms", to appear Eurocrypt'96.
[X509] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
Security Considerations
This entire document is about security.
Authors' Addresses
Eric Rescorla
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303
Phone: (650) 328-8631
EMail: ekr@rtfm.com
Allan M. Schiffman
SPYRUS/Terisa
5303 Betsy Ross Drive
Santa Clara, CA 95054
Phone: (408) 327-1901
EMail: ams@terisa.com
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.