WD-sigs-960311
WD-sigs-960311This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
A mechanism for adding non-repudiable authentication of resources to the HTTP protocol using public key signatures and an infrastructure to provide warning when signatures are invalid or missing is described.
It is often desirable to authenticate a HTTP accesible resource in a non-repudiable manner. This is of particular importance where authoratative documents such as court records, contract offers and press releases are published where an attacker may have a finacial incentive for forgery. Another important application area is in the distribution of source and executable instruction codes where the consequences of malicious code modification may be serious.
This paper does not describe a mechanism for establishing trust. Instead it provides a means of enforcing an established trust policy.
This paper does not describe a mechanism for negotiating the manner in which a resource is signed or the key under which it is signed. It is beleived that such negotiation is orthogonal to the protocol encoding of signatures. Negotiation is left to a generic HTTP mechanism such as the proposed Protocol Extension Protocol (PEP) [Khare96].
In some cases it is desirable to perform a digital signature operation in advance of a resource being distributed. For example where a server acts as a secondary site (mirror) for another the ability to generate signatures may be limited to the originating site.
It is highly desirable to permit signatures to be applied to dynamically created content such as live video, audio or text streams. In such cases it is not possible to generate a signature before part or all of the message has been transmitted.
The signature protocol extensions are designed to be used within an application framework providing a convention for labeling keys and a convention by which the existence of digital signatures can be asserted. We illustrate the use of these facilities with an example scenario.
Richard's Software Foundation (RSF) wishes to distribute software. Users of RSF software wish to ensure that they download only genuine copies of the code and not code which may have been tampered with. Because of the popularity of RSF software it is avaliable from a number of servers arround the world. Since the administrators of these sites have only an informal relationship with RSF it is undesirable for them to require access to the private component of the RSF public key.
Whenever a new software release is made RSF signs the file containing the code using the official RSF key, RSA:MFowC....vfeA62WzAg:MBAAE (here truncated for ease of reading). The file and signature are then distributed to each RSF mirror site using the HTTP POST method.
RSF software changes frequently and users are keen to obtain the latest version. Users would like to be able to download and run binary files with an assurance that the code is correct. Users know that RSF software is digitally signed using the RSA:MFowC...vfeA62WzAg:MBAAE key from the documentation of the last RSF product which they used and in every new RSF software announcement. It may also be reported in USEnet newsgroups, Frequently Asked Questions lists and other pervasive sources of information. The reputation of the signature matches that of the resource being verified.
The user appends the following assertions to their client's assertion database:
ASSERT: http://www.rsf.org/%*; signed=RSA:MFowC....vfeA62WzAgMBAAE= ASSERT: http://www.ai.mit.edu/pub/rsf/%*; signed=RSA:MFowC....vfeA62WzAgMBAAE= ASSERT: http://www.hensa.ac.uk/software/rsf/%*; signed=RSA:MFowC....vfeA62WzAgMBAAE=
These assertions inform the client that each resource matching the given URI template is signed using the specified key. If the client recieves a resource which contradicts the assertion an exception is raised. Alternatively a client might be configured to prohibit certain operations on a file unless it matched one or more assertion templates. A client might be configured client to only download files into the /rsf directory if they complied with the RSF assertion list.
An attacker might theoretically ensure that a victim remained unaware that RSF software was signed using a man-in-the-middle attack. Such an attack would require complete control of the victims communication channels and could equally well trick the user into using Mallet's Software Foundation.
The RSF has a large and changing number of mirror sites arround the world. New sites appear regularly and old sites are frequently reorganised. It is convenient to avoid requiring the users to administer individual assertion lists by hand. Delegation permits the assertion list to be maintained by another party, in this case the RSF:
Delegate: http://www.rsf.org/security/assertion_list; signed=RSA:MFowC....vfeA62WzAgMBAAE=
The delegated assertion list is authenticated, in this case with a non repudiable signature. The signed list of assertions is thus a certificate.
Assertions are monotonic. A delegated assertion list cannot be used to instruct a client to ignore an assertion specified elsewhere. Care must be taken when ascribing privilleges to delegated lists however since the controller of the delegated lists is effectively granted to the controller of the list.
It is often desirable for an assertion to refer to the holder of a key rather than a key itself. In the example given we may prefer to state that the RSF signs its keys with the RSF key KEY:RSA:rsf.org rather than specify the particular key to be used. Named keys may be considered the cryptographic equivalent of DNS host names (e.g. rsf.org) rather than IP addresses (e.g. 18.23.1.191).
Named keys are shorter and more recognisable to users. The right to use the KEY:RSA:rsf.org may be legaly bound to the rights to the DNS rsf.org domain wheras the RSA keys can in themselves imply no similar binding. Named keys also permit assertions to be made independent of the particular cryptographic key used. This is of particular importance where an individual changes a key at regular intervals.
Despite the advantages of named keys they also introduce significant additional complexity. The binding of the name to the key must be specified in a manner which can be trusted by the recipient. This requires the establishment of a system of trust which is a highly complex undertaking in itself.
Keys may be bound to a name through a signed assertion (certificate). A number of certificate formats are specially designed for this purpose (e.g. X.509). Work is currently underway in the IETF to standardize a simple public key infrastructure. The following construct might be included within an assertion list to establish such a binding:
Bind: KEY:RSA:rsf.org; key=RSA:MFowCgYEVQgBAQICAgoDTAAwSQJCAyg/Mjlgv/o+1ui95Um eeYiqUlDFFDDEaD0fHCcuR1DXS3cCGp3LJl4plprCxEApQCH1eBt/7Ia/EkESvfeA62WzAgM:BAAE
One extension to the HTTP/1.1 protocol [HTTP-1.1] is proposed, the Signature header. This allows signatures to be added to either the header or the footer of the message. Placement of the signature in the message header permits backwards compatibility with HTTP/1.0 [HTTP-1.0]. Placement of the signature in the footer permits dynamically created content to be signed.
These protocol extensions are specified using the augmented BNF used to describe the HTTP protocol.
Entity-Header = Allow | Content-Encoding | Content-Type ... | Content-Signature
Footers are introduced in the HTTP/1.1 specification. For the time being it is convenient to specify this as a separate Entity-Footer list since the current specification of chunked may need amendment:
Entity-Footer = Content-Digest | Content-Signature
The Content-Signature header appears in the header and either specifies a digital signature and key or signals to the receiver that a signature is present in the footer.
Content-Signature = "Signature" ":" 1#signature-attr signature-attr = "digest-dig" "=" digest-alg | "key-id" "=" key-id | "data" "=" data | "pos" "=" "footer" digest-alg = "RSA-MD5" | "SHA" | extension-digest-alg key-id = URI data = <base64 encoding of signature>
Where the attributes digest-alg, key-id data and pos pos have the following definition:
The value of the data field is defined by the signature algorithm, the public key and the HTTP entity alone. Meta-data relating to the entity but not a part of such as Content-Type are not included in the digest. i.e. data is given by:
data = sig-alg (key-id, digest-alg (entity))
Where sig-alg is the signature algorithm function defined by the type of key-id.
The following example shows a digital signature in the header of a HTTP reply. This usage is compatible with HTTP/1.0 clients and servers.
HTTP/1.1 201 O.K. Here is some data
Content-Length: 82
Content-Type: text/html
Content-Signature: digest-alg=RSA-MD5; key-id=KEY:RSA:rsf.org;
data=fLQk4ZyOdUbuoldrNTPX3P/Yb6PXXhS9xCnTe9xMihEdvDt66rXDpf34N
AzfjayyWWfekM2qArK+xqcUNbxOZw==
Server: test/1.0
<BODY><H1>This is a test Message</h1><p>Hello</p><HR><address>PHB</ADDRESS></body>
The following example shows the use of a chunked transfer encoding to allow the signature to be given at the end of the message. This facility permits dynamically created content to be signed in real-time. The Content-Signature header alerts the client that a signature will be specified in the footer and provides information permitting the client to decide wether to check the signature and if so which digest algorithm to use.
HTTP/1.1 201 O.K. Here is some data
Content-Length: 82
Content-Type: text/html
Server: test/1.0
Transfer-Encoding: chunked
Content-Signature: digest-alg=RSA-MD5; key-id=KEY:RSA:rsf.org; pos=footer
20
<BODY><H1>This is a test Message
21
</h1><p>Hello</p><HR><address>PHB
10
</ADDRESS></body>
0
Content-Signature: digest-alg=RSA-MD5; key-id=KEY:RSA:rsf.org;
data=fLQk4ZyOdUbuoldrNTPX3P/Yb6PXXhS9xCnTe9xMihEdvDt66rXDpf34N
AzfjayyWWfekM2qArK+xqcUNbxOZw==
Keys are specified using key identifier URIs (key-ids for short). Two sorts of Key-ids are used, absolute keys and named keys. Absolute keys are an ascii representation of the actual value of a cryptographic key. Named keys are references to keys consisting of a key algorithm and a key name. The following types of key-id are defined:
It is likely that other cryptographic operations (e.g. encryption) will motivate the specification of additional types key-id.
RSA key URIs have the following form:
RSA:public:modulus
Where modulus and public are the base-64 encoded RSA modulus and public exponent respectively. The sig-alg function for RSA keys is defined as follows:
sig-alg (key, entity) = pkcs-1 ((public ^ entity) mod modulus)
Where pkcs-1 is the PKCS#1 packing format for public key operations.
To Be Specified (perhaps).
Assertion lists list statements which are believed to be true. The signature mechanism requires three types of statements. Simple Assert statements are used to state sets of URIs which are signed under a particular key. Delegate statements specify a location at which a reliable assertion list may be found. Bind statements state the value of a key.
The syntax of assertion lists is independent of the HTTP protocol. An RFC-822 [RFC-822]like syntax is used since it may prove convenient to incorporate assertions into HTTP headers in a future version of the specification.
Assertion-List = #Assertion
Assertion = Assert
| Bind
| Delegate
Assert = "Assert" ":" template #(";" assert-param)
assert-param = "signed" "=" key-id
Bind = "Bind" ":" key-id key-id
Delegate = "Delegate" ":" URI #(";" assert-param)
The following design decisions could be changed without affecting the semantics of the signatures proposal:
The examples given were constructed using code which used named keys rather than the absolute keys referred to in the text. The examples should be re-generated after this has been done.
This paper presents a scenario before providing a broad overview of the application of the scheme.