All files shared on a LionShare network have an associated metadata structure. This structure contains, at a minimum, a cryptographic hash of the file[5], the "server" certificate of the last user to alter this file, as well as the certificate chain for this "server" certificate. Most files' metadata structures will also have "traditional" metadata (such as ID3 tags) encoded as a stream of XML. The format of this metadata (Dublin Core, IEEE-LOM, etc) is not specified by LionShare. Crucially, this entire metadata structure contains a digital signature of itself; this signature is generated by the peer's "server" certificate.

These metadata structures are stored in a relational database inside the LionShare application. When a user alters a file's metadata structure, either by editing the structure itself, or by altering the file (which would change the file's hash), the metadata structure must be re-signed. This is done using the user's current "server" certificate. No attempt is made to track revisions to a metadata structure.

This scenario does present a problem. As discussed in the Obtaining Credentials section, a user's "server" certificate is destroyed when the user closes the LionShare application, but the metadata structures (and their digital signatures) are not destroyed at shutdown -- they are persisted into an embedded relational database. When the user next launches LionShare, a new "server" certificate will be obtained from the SASL-CA. However, the metadata structures are not re-signed with the new "server" certificate, since re-signing large filesets would be prohibitive. Instead, the metadata structures (and their digital signatures) are retrieved from the database and made available for other peers to query.

Therefore, it is possible that a user will receive a metadata structure signed with an expired certificate. In traditional X.509 certificate processing, this would raise an error. In LionShare, expired certificates are allowed. If the metadata's digital signature is valid, then the included "server" certificate must have been used to sign it. Since a valid certificate was used to sign the metadata, it is assumed that the metadata is legitimate.