|
|
3.5 Modifying records and Modified VEOs
When a recordkeeping system holds folders and records internally in the VEO format the digital signatures prevent the contents of those folders and records from being modified. Accordingly, in both Version 1 and Version 2 of the Standard there is a mechanism that allows a new, modified version of a record to be created which contains the original record complete with digital signatures. In Version 1 this mechanism was known as an 'Onion' record, and only allowed a Record VEO to be modified. In Version 2 a new mechanism has been defined (known as a 'Modified VEO') that allows for the modification of both records and folders.
Recordkeeping systems that only produce VEOs upon export need not implement either mechanism. Version 2 systems must only generate Modified VEOs and must not use the onioning mechanism. Version 2 systems that can import VEOs must be able to handle Version 1 VEOs, including those that have been produced using the onion mechanism.
3.5.1 'Onion' records
Version 1 allowed Record VEOs to be modified by onioning. This approach is shown in Figure 8. To modify a Record VEO, a new Record VEO (the 'Onion VEO') is created. The new Record VEO contains the complete original VEO, including the original digital signatures, as a Document. The new Record VEO also contains the modified record metadata. Since the new Record VEO contains the unaltered original VEO, complete with digital signature, the integrity of the original VEO can still be verified. The digital signatures on the new Record VEO cover both the new modified Record Metadata and the original VEO, and so the integrity of the modified metadata and the relation with the original VEO is protected. If necessary, this process can be repeated by wrapping the modified Record VEO within a new VEO, hence the 'onion' analogy.
Figure 8. Creation of an onion record. The original VEO is included complete within the new VEO as a Document.
The process of onioning has three problems:
- It is not possible to modify any of the Documents within a record. In particular it is not possible to:
- Add additional Documents. This may need to occur if the user omits a relevant Document from the record.
- Delete Documents. This may need to occur if a Document has been incorrectly incorporated in the record.
- Modify the metadata associated with a Document or Encoding. This may need to occur if a Document or Encoding has been incorrectly described.
- Add an Encoding to a Document. This may occur if a long-term preservation format is replaced by a new preservation format and all instances of the old format are migrated.
- Delete an Encoding from a Document. This may occur when a particular format can no longer be processed.
- It is possible to discard modifications. Consider the onion VEO in Figure 8. It is possible to extract the original VEO from the onion record, and this extracted VEO will be a perfectly valid VEO. If it was then possible to replace the onion VEO in the recordkeeping system with the original VEO, the modifications would have been effectively discarded with no way of determining that this discarding occurred. As there may be more than one layer of modifications, it is clear that any number of layers of the onion can be discarded.
- It is not possible to modify a File VEO as the onion mechanism was only defined for Record VEOs.
These three problems are the reason why the 'Modified VEO' has been added to Version 2 of the standard.
3.5.2 Modified VEOs
A 'Modified VEO' is a type of VEO and is contained within a Signed Object (M4) element.
The Modified VEO allows the contents of a VEO to be modified. The basic mechanism is exactly the same as that used when creating an onion record. A Modified VEO contains the signed object and digital signatures from the original VEO, the object representing the revised VEO, and digital signatures to lock the two states together. Unlike an Onion VEO, a Modified VEO can contain any type of VEO; including a Record VEO, a File VEO or another Modified VEO. The latter allows for layers of modifications to be built up.
In describing how to use the Modified VEO, the expressions 'Original Record' and 'Revised Record' will be used, as these concrete terms make the description much easier to follow. However, they are slightly misleading, and readers should remember that:
- Any type of VEO may be included in a Modified VEO, not just a record.
- The 'Original Record' may be another Modified VEO (i.e. the record or file could already have been altered).
Figure 9. The general structure of a Modified VEO.
The contents of a Modified VEO are:
- Date/Time Modified. This element contains the date and time the element was modified. It is included primarily so this information can be easily obtained when displaying the modifications to a user.
- Revised VEO. This element contains a Signed Object containing the Revised VEO. No signature blocks are included as the integrity is preserved by the normal Signature Blocks in the VERS Encapsulated Object. Note that this element contains a 'vers:id' attribute which identifies this revision of the VEO.
- Original VEO. This element contains the relevant parts of the VEO that has been modified. These parts are:
- Signed Object. This is a copy of the Signed Object (M4). The content of the Signed Object (M4) may be a Record VEO, a File VEO, or another Modified VEO.
- Signature Block. These are copies of the Signature Blocks (M134).
Since the Modified VEO contains the unchanged Signed Object and Signature Blocks from the VEO that has been modified, it remains possible to verify the digital signature and hence the integrity of the record.
Note that the Original VEO element does not contain the entire original VEO. It does not contain the VEO Format Description (M2), Version (M3), or Lock Signature Block (M152) elements.
The easiest way to explain the features of a Modified VEO is to work through the process of creating a Modified VEO. In working through this process, please note:
- The Revised VEO contains all of the metadata of the VEO, not just that content which has been modified.
- The Revised VEO does not contain unmodified data files (e.g. PDF files). Instead, it contains a link to the original data buried in the Original VEO.
- The use of the Lock Signature to prevent any extraction of the Original VEO and then discarding of the Modified VEO.
Process of creating a Modified VEO
We will assume that a Record VEO is to be modified (a similar process is used for a File VEO or Modified VEO). The process of creating a Modified VEO is as follows:
- Check integrity of VEO. The first step is to validate the digital signatures on the VEO, including the Lock Signature if the VEO is a Version 2 VEO. The validation of the signatures should be documented in the Management History (M66) If any of the digital signatures do not validate this should be documented, but this does not prevent modification of the VEO.
Determining that the VEO is Version 2 must be done from examination of the Version attribute found in the Signed Object (M4) element and not by examination of the Version (M3) element. This is because the Version element is not protected by the digital signatures and hence a forger could alter the version from Version 2 to Version 1 and then remove the Lock Signature.
- Extract VEO contents. Next, the Signed Object (M4) and Signature Blocks (M134) are extracted from the VEO and placed in the Original VEO (M159) element.
Note that the Original VEO (M159) does not contain the entire VERS Encapsulated Object (in this it is unlike an 'onion' record). Specifically, it does not contain the VEO Format Description (M2), Version (M3), or the Lock Signature Block (M152).
- Construct the contents of the Revised VEO. A copy of the original Signed Object (M4) is made and all the necessary modifications are made to it. These modifications may include:
- Revised Record Metadata
- Addition of a new Document
- Removal of an existing Document
- Modification of the Document Metadata
- Addition of a new Encoding to a Document
- Removal of an existing Encoding from a Document
- Modification of the Encoding Metadata
- Replacement of the Document Data in an Encoding
Important: When constructing a Modified VEO, a Management Event (M67) must be created in the Management History (M66) documenting the modification. The Management Event must contain:
- An Evvent Type (M69) of 'Record Modified' or 'Folder Modified'
- An Event Description (M70) describing why the record or folder was modified and, if possible, how the record or folder was modified. We recommend that if a small number of changes are made to a VEO these changes be listed in the Event Description. When a large number of changes are made, however, each change need not be individually listed. It would then be up to a researcher to manually compare the Original and Revised VEOs to determine the changes.
This modified copy is placed in the Revised VEO (M158) element.
Note that the Revised VEO (M158) element contains the full current state of the VEO including the elements that have not been changed. Consequently, it can be used to answer user queries without reference to earlier versions of the VEO.
Because information is duplicated, a Modified VEO is consequently large. We considered holding only those elements that had changed, but the disadvantage of this was that to view the record it would be necessary to merge all of the changes. This would not only take significant amounts of processing time for an operation that is commonly performed, but was potentially error prone. If a mistake was made in constructing the list of changed elements, for example, it would not be possible to subsequently correct the mistake.
- Remove unmodified copies of Encodings. To reduce the size of the Revised VEO (M158), any Document Data (M133) that has not been changed is deleted and replaced by a reference to the original data.
Figure 10: A Modified VEO with one Document that has not changed, one document that has been added, and one Document that has been deleted.
Figure 10 shows the three possibilities for handling Documents. Revised VEO/ Document 2 is unchanged and so includes a reference to the original data instead of duplicating the data. Revised VEO/Document 1 is a new Document and so includes the full document data. Original VEO/Document 2 has been removed from the record and so does not appear in the Revised VEO (but note that the Document is still present in the VEO).
The following XML fragment shows the Modified VEO from Figure 10:
[...]
<vers:SignedObject vers:VEOVersion="2.0">
[...]
<vers:ObjectContent>
<vers:ModifiedVEO vers:OriginalVEOType="Record">
<vers:DateTimeModified>
2003-03-31T15:26:07-10:00
</vers:DateTimeModified>
<vers:RevisedVEO vers:id="Revision:2">
<vers:SignedObject vers:VEOVersion="2.0">
[...]
<vers:Record>
[...]
<vers:Document vers:id="Revision:2-Document:1">
[...]
<vers:Encoding vers:id="Revision:2-Document:1-Encoding:1">
[...]
<vers:DocumentData vers:id="Revision:2-Document:1-Encoding:1-DocumentData">
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAiwEAAA
[...]
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
</vers:DocumentData>
</vers:Encoding>
</vers:Document>
<vers:Document>
[...]
<vers:Encoding vers:id="Revision:2-Document:2-Encoding:1">
[...]
<vers:DocumentData
vers:id="Revision:2-Document:1-Encoding:2-DocumentData"
vers:forContentsSeeElement="Revision:1-Document:1-Encoding:1"/>
</vers:Encoding>
</vers:Document>
</vers:Record>
</vers:ObjectContent>
</vers:SignedObject>
</vers:RevisedVEO>
<vers:OriginalVEO>
<vers:Version>2.0</vers:Version>
[...]
<vers:SignedObject vers:VEOVersion="2.0">
[...]
<vers:Record>
[...]
<vers:Document vers:id="Revision:1-Document:1">
[...]
<vers:Encoding vers:id="Revision:1-Document:1-Encoding:1">
[...]
<vers:DocumentData
vers:id="Revision:1-Document:1-Encoding:1-DocumentData">
JVBERi0xLjMNJeLjz9MNCjkwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA5MiANL0
[...]
JUVPRg0=
</vers:DocumentData>
</vers:Encoding>
</vers:Document>
<vers:Document vers:id="Revision:1-Document:2">
[...]
<vers:Encoding vers:id="Revision:1-Document:2-Encoding:1">
[...]
<vers:DocumentData
vers:id="Revision:1-Document:2-Encoding:1-DocumentData"
JVBERi0xLjMNJeLjz9MNCjkwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA5MiANL0
[...]
JUVPRg0=
</vers:DocumentData>
</vers:Encoding>
</vers:Document>
</vers:Record>
</vers:ObjectContent>
</vers:SignedObject>
</vers:OriginalVEO>
</vers:ModifiedVEO>
</vers:ObjectContent>
</vers:SignedObject>
</vers:VERSEncapsulatedObject>
The reference to the original Document Data is contained in an attribute in the Document Data (M133) element. The attribute depends on whether the original data was in a Version 1 VEO or a Version 2 VEO.
- Version 2 VEO. References to a Document Data element in a Version 2 VEO are made using the 'vers:forContentsSeeElement' attribute.
A Document Data element in a Version 2 VEO must contain an vers:id attribute with the value 'Revision:LL-Document:DD-Encoding:EE-DocumentData' where 'LL' is the revision number (1 being the very first VEO, 2 being the first encapsulating ModifiedVEO, 3 being the second ModifiedVEO and so on), 'DD' being the number of the Document within that layer (1 being the first Document), and 'EE' being the number of the Encoding within that Document (1 being the first Encoding). So 'Revision:1-Document:3-Encoding:2' would be the second Encoding in the third Document of the original VEO.
Note that the value of the vers:id attribute reflects the position of the Document Data element within the VEO and will change each time the VEO is encapsulated within a Modified VEO, even if the Encoding does not change. So, for example, in Figure 9 the unchanged Document is 'Revision:1-Document:1-Encoding:1' in the original VEO and 'Revision:2-Document:2-Encoding:1' in the revised VEO.
- Version 1 VEO. A Document Data element in a Version 1 VEO will not contain an vers:id attribute. In this case the reference is contained in a vers:forContentsSeeOriginalDocumentData attribute.
The value of this attribute is in the same form as previously ('Revision:LL-Document:DD-Encoding:EE'), the use of the different attribute indicating that the system must locate the relevant Document Data element itself rather than using the inbuilt XML operations.
The Document Data reference must always point directly to the element that actually contains the Document Data content. When a VEO is modified for the second or subsequent time (i.e. when one Modified VEO encapsulates another Modified VEO) the reference in the second Modified VEO should point to the original, not to the first Modified VEO.
An example of the use of these attributes is shown below.
Figure 11. Sequence of modifications to a VEO showing use of vers:forContentsSeeElement and vers:forContentsSeeOriginalDocumentData attributes to refer to Version 1 and Version 2 Documents.
- Construct Revised VEO. The copy of the Signed Object (made in step 3 and modified in steps 4 and 5) is inserted in a Revised VEO (M158) element. The Revised VEO element contains a 'vers:id' attribute that identifies this revision. Note that the original VEO is considered to be revision 1, and so the first revised VEO is revision 2, and so on.
- Construct Modified VEO. The Revised VEO (M158) and the Original VEO (M159) elements are used to make a Modified VEO (M156) element.
The Modified VEO element contains a vers:OriginalVEOType attribute. This contains the value 'Record' or 'Folder' depending on whether the original VEO was a record or folder. This attribute can be used by an application to determine whether a Modified VEO contains a Record VEO or a File VEO without examining the contents of the Revised VEO.
The Modified VEO is inserted as the Signed Object in a new VEO. Finally, new Signature Blocks and a new Lock Signature are applied.
Accessing the contents of a Modified VEO
The following description gives the process for accessing information in a record (the most common case), but the process for other types of VEOs is similar.
- When it is necessary to access the metadata, it is only necessary to use the copy of the Record VEO (M10) element held inside the Revised VEO (M158) element. The Record VEO contains the current state of all the metadata.
- When it is necessary to access the content of a document, the first point of call is the latest copy of the Record VEO (M10) element held inside the Revised VEO (M158) element. If that Document or Encoding was added (or modified) in the last modification, the actual content will be found in the Document Data (M133) element. In the more usual case, however, the Document Data (M133) will have been unchanged and will not contain any content. In this case the reference in the vers:forContentsSeeElement or vers:forContentsSeeOriginalDocumentData attributes will have to be followed to the data inside the Original VEO element.
3.5.3 Lock Signature Blocks
Lock Signature Blocks (M152) are used to prevent tampering with the record by stripping off the outermost layer of a Modified VEO and discarding the modifications. This problem affected the original 'onion' modification process (see section 3.5.1). The problem arises because the original VEO is held intact within the onion. The solution is to remove a piece of information from the original VEO when it is modified so that original VEO cannot be extracted. The information removed is the Lock Signature Block.
A Lock Signature Block (M152) only appears in a VERS Encapsulated Object. The process of applying a Lock Signature Block is as follows:
- The VEO is signed (see section 5), producing a Signature Block (M152). This signature block element contains an vers:id attribute with the value 'Revision:LL-Signature:SS', where 'LL' is the revision number (1 being the very first VEO, 2 being the first encapsulating Modified VEO, 3 being the second Modified VEO and so on), and 'SS' being the number of the Signature Block within that layer (1 being the first signature).
- The Signature element (M138) is then signed using the same private key used to produce the Lock Signature Block (M152) (see Figure 12). The Lock Signature Block element must contain a vers:signsSignatureBlock attribute which identifies the Signature Block containing the Signature that has been signed.
Figure 12. The signature in a Lock Signature Block signs the signature element from one of the Signature Blocks. Which Signature Block is indicated by attributes.
As described in the previous section, the Lock Signature Block is discarded when a VEO is modified and the Signed Object becomes part of the Original VEO (M159) element of a Modified VEO. To discard the outermost layer of a Modified VEO, a forger would need to recreate the Lock Signature Block. To do this, the forger requires the private key of the recordkeeping system.
Note that the use of a Lock Signature Block is not complete protection against forgery. If the forger knows, before modifying a VEO, that they will want to subsequently discard the modification, they can simply make a copy of the Lock Signature before modifying the VEO. Lock Signature Blocks will only protect the against forgers attempting to retrospectively discard modifications.
back to top
printer friendly
|
