A giftfile certificate is the metadata required for a nonproprietary intellectual work, existing in file form, to participate in the giftfile system. The key elements of a certificate are:
Several aspects of a certificate make it cryptographically secure. For example, it is digitally signed by the publisher. This allows one to verify claims that a given certificate was created by a certain entity, and to link the certificate with other data related to that entity. Another aspect is that references to file resources include a cryptographic digest. This allows verification that a given file is indeed the one referred to by the certificate.
As an example, we are going to present a certificate related to a fictitious work and publisher. This certificate happens to be for a binary package of version 0.92 of a software program called "SuperFoo".
<Certificate
xmlns="http://giftfile.org/ns/giftfile/0.0"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:pgp="http://giftfile.org/2004/02/openpgp#">
<Issued>2004-05-28T16:52:38Z</Issued>
<Work URI="http://foofactory.example/releases/SuperFoo#0.92">
<Name>SuperFoo version 0.92</Name>
<Source>
<dsig:Reference URI="http://foofactory.example/files/superfoo_0.92.tgz">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>cT133NNRTmmIpiY8awUkCMXKf8M=</dsig:DigestValue>
</dsig:Reference>
</Source>
<Binary>
<dsig:Reference URI="http://foofactory.example/files/superfoo_0.92-1_i386.tgz">
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>ovNc0UNnL2EwK30JK+zRr1PuLYI=</dsig:DigestValue>
</dsig:Reference>
</Binary>
<Rights>
<License URI="http://giftfile.org/known_licenses#MIT">
<Copyright>
<Year>2004</Year>
<Claimant>Fracis Foo III</Claimant>
</Copyright>
</License>
</Rights>
<SuggestedDonation>
<Value>0.75</Value>
<Currency>USD</Currency>
</SuggestedDonation>
</Work>
<Series URI="http://foofactory.example/products#SuperFoo">SuperFoo</Series>
<Publisher URI="http://foofactory.example/">
<dsig:KeyInfo>
<pgp:Fingerprint>Am9o7787NU04yB6+VJBdM2p6EuM=</pgp:Fingerprint>
</dsig:KeyInfo>
</Publisher>
<Giftpool URI="http://test-giftpool.giftfile.org/">
<dsig:KeyInfo>
<pgp:Fingerprint>RPkavW3BIM+KM+EUWabQVeI0eM4=</pgp:Fingerprint>
</dsig:KeyInfo>
</Giftpool>
<dsig:Signature>
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://giftfile.org/2004/02/openpgp#signature"/>
<dsig:Reference URI="">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>Qu/j7RHnLQftzB0ZJaP9MwPuXSo=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>iD8DBQBAt25WVJBdM2p6EuMRAl3AAJ9OJzpDtOJHJoavPSgC+Rxt1nUGtACgmzFE9NvrEh7R3D/J
2aUPLR9SG8g=</dsig:SignatureValue>
</dsig:Signature>
</Certificate>
That is a lot to study, so rather than step through it line by line, we'll skim through it and note the interesting parts along the way.
In addition to the obvious use of the XML standard, other standards such as XML Signature are employed. XML Signature itself is quite verbose, and for our purposes we can just refer to the last 25% of the certificate as "the publisher signature". Note that the signature is enveloped, meaning that it exists within the data being signed—in this case, the root <Certificate> element. Also worth noting is that certificates make use of an XML Signature extension which allows better support for PGP cryptography. This is required because PGP is used for all identities in the giftfile system.
Returning to the top of the certificate, we see a large section which details the work itself. The work, like most items in the certificate, has a URI associated with it. With the notable exception of file references, which we'll cover shortly, these URI's are optional. They may link to a web page which provides more information about the resource, or they may simply be an identifier. The purpose of these URI's is to allow the publisher to make associations between the certificate and things in the outside world.
Included in the work section is a reference not only to the binary package (superfoo_0.92-1_i386.tgz), which happens to be the focus of this certificate, but also to the source package (superfoo_0.92.tgz). This is a situation mostly unique to software, where a work can be considered nonproprietary only if the source code is available. Certificates for software works published in source form only, and for most works that are not software, will not have a binary file reference.
File references deserve a little more attention. They include a cryptographic digest of the file, and a URL which must resolve to a resource matching the digest. The URL must lead to the file resource without human intervention (i.e., without web page navigation). The purpose of this URL is not to provide a canonical download location for the file. Rather, it is intended as proof that the file is published—a requirement for it to be considered nonproprietary. Should publishers be concerned about providing a stable URL, services are available, some free, which provide URL redirection. Should they be concerned about hosting or bandwidth requirements, organizations exist which are willing to host most files containing nonproprietary works.
Back to our example, the file references are followed by a description of the rights allowing the work to be published. In this case, the rights are simple: SuperFoo has a single author, and he has placed the work under the MIT software license. For works created by more than one author, and for aggregate works, the rights information can get quite large. However, the information provided is essential. In the case of copyrighted works, without suitable permission from every copyright holder, the work cannot be considered nonproprietary. In summary, the publisher is making a statement as to why he can publish the work and why the work qualifies as a giftfile.
Between the section describing the work and the publisher's digital signature, there are only a few more items. One is a series identifier. This can be used by a publisher to group his giftfiles. Normally, this is used to associate different revisions of an ongoing work. In this example, we see that the subject of this certificate (SuperFoo v0.92) is part of the SuperFoo series.
What remains is the identity of the publisher and the identity of the publisher's giftpool. Each identity includes a PGP fingerprint. Unlike the hex encoding which is common for fingerprints, here base-64 encoding is used in order to be consistent with XML Signature.
$LastChangedDate: 2004-05-28 17:29:02 -0400 (Fri, 28 May 2004) $